Book of Implementation Guidelines PFCS Vendor Specification

Transcription

1 Manufacturing Engineering PFCS Vendor Specification Revision Date: 07/25/11 Page 1 of 138 Revision: 2.4

2 Proprietary Notice This document comprises legally protected subject matter proprietary to Chrysler, and is loaned on the basis of confidential relationship. All use and disclosure is strictly controlled. Reproduction is prohibited without the permission of Chrysler. Documentation Standards, Version 2.0 Copyright 2007, Chrysler. All Rights Reserved. Revision Date: 07/25/11 Page 2 of 138 Revision: 2.4

3 Table of Contents 1.0 GENERAL PURPOSE SCOPE USERS DEFINITIONS PFCS DEVICE CATEGORIES AND CERTIFICATION REQUIREMENT CERTIFICATION REQUIREMENT PFCS DEVICE CATEGORIES SUPPLIER COMMUNICATION INTRODUCTION PFCS PROTOCOL OVERVIEW MESSAGE STRUCTURES MACHINE ID MESSAGE TYPES CONNECTION TYPES/TWO PORT COMMUNICATIONS CONNECTION STATUS DISPLAY PFD LOGGING AND DEBUGGING MESSAGES DOCUMENTATION ENABLE/DISABLE COMMUNICATIONS AT PORT LEVEL COLLISION PROCESSING ERROR RECOVERY PROCESSING SPD SUPPLIER INFORMATION PFCS CONNECTIVITY SPECIFICATIONS PFD SINGLE PORT COMMUNICATIONS (BACKWARD COMPATIBLE) TWO PORT - UNSOLICITED AND SOLICITED COMMUNICATIONS TORQUE MONITORING SEQUENCE OF OPERATIONS KEY DEFINITIONS NUTRUNNER TOOLING DATA FORMATS REQUESTING VEHICLE BUILD DATA RECEIVING VEHICLE BUILD DATA SENDING VEHICLE SEQUENCING MESSAGES PFD RESULTS RECORD FORMATS VENDOR CERTIFICATION PRE-LAB DOCUMENTATION LAB CERTIFICATION PROCEDURES INTEGRATED TESTING Revision Date: 07/25/11 Page 3 of 138 Revision: 2.4

4 6.4 PFD DOCUMENTATION APPENDIX A: PFCS TEST CHECK LIST Revision Date: 07/25/11 Page 4 of 138 Revision: 2.4

5 APPENDIX B: GLOSSARY & CONDITIONS TERMS & CONVENTIONS REVISION HISTORY Revision Date: 07/25/11 Page 5 of 138 Revision: 2.4

6 Table of Tables Table 1: Message Format Table 2: ACK and NAK Message Format Table 3: Valid PFCS Message Types Table 4: Error Codes Possible In an ACK/NAK Record Table 5: Error Codes Generated by the PFD Table 6: Error Keep Alive Message new format Table 7: SPD Record Layout Including Record Header Table 8: Modem Configuration Table 9: Female Connectors (Pin Assignments and Descriptions) Table 10: Device Categories Table 11: Style Request and Test result matrix Table 12: Two Port Communication Automatic Mode Table 13: Two Port Communication Backup Data Recovery Method Table 14: Two Port Communication Manual Mode Table 15: Machine ID Determination Table 16: PFD Format Used to Request Vehicle Data from PFCS Table 17: PFD Format Used to Request Vehicle Data from PFCS Using AVI Barcode Data Table 18: PFD Format Used to Receive Vehicle Data from PFCS Table 19: PFD Format Used to Receive Vehicle Data as Unsolicited Message Table 20: PFD Format Used to Sending Vehicle Sequencing Messages Table 21: PFD Record Headers Using VIN/TRACK Table 22: PFD Record Headers Using AVI Barcode Table 23: Torque Monitor Results Format Table 24: Example Record Format of Results for Fill Equipment Table 25: Example Record Format from Glass Verification Stations Table 26: Example Record Format from Door Test Equipment Table 27: PFD Format Kanban Messages Including PFCS Header Table 28: PFD Format Mistake Proof Style Data Formats Including PFCS Header Table 29: PFD Format Mistake Proof Results Data Format Table 30: PFS Send Truth Table Table 31: Terms and Conventions Revision Date: 07/25/11 Page 6 of 138 Revision: 2.4

7 Table of Figures Figure 1: Data Flow Diagram Figure 2: Request for Vehicle Data Figure 3: Unsolicited Vehicle Data Figure 4: Unsolicited Vehicle Data with NAK followed by an ACK Figure 5: Sending Test Results to PFCS Figure 6: Message Format Figure 7: ACK and NAK Message Format Figure 8: Typical Multi Machine Workcell Figure 9: Connector Diagram Figure 10: Single Machine ID Single Spindle Single Channel Figure 11: Machine ID Determined By Process Single Spindle - Single Channel Figure 12: Machine ID Determined By build code received Single Spindle - Single Channel Figure 13: Single Machine ID Single Spindle - Multiple Channel Figure 14: Multiple Machine ID Single Spindle - Multiple Channel Figure 15: Machine ID Determined By Process Single Spindle - Multiple Channel Figure 16: Machine ID Determined By Build Code received Single Spindle - Multiple Channel Figure 17: Group Mode Single Spindle - Multiple Channel Figure 18: Group Mode Single Spindle - Multiple Channel, Multiple Machine IDs Figure 19: Single Machine ID Multi Spindle - Single Channel Figure 20: Machine ID Determined By Process Multi Spindle - Single Channel Figure 21: Machine ID Determined Build code received Multi Spindle - Single Channel Figure 22: Single Machine ID Multi Spindle - Multi Channel Figure 23: Multiple Machine ID Multi Spindle - Multiple Channel Figure 24: Machine ID Determined By Process Multi Spindle - Multiple Channel Figure Figure 25: Machine ID Determined By Build Code received Multi Spindle - Multiple Channel Figure 26: Example of Message Type 9999 (Requesting Machine Name) with old keep alive format Figure 27: Example of Message Type 9999 (Requesting Machine Name) with new keep alive format Figure 28: Example of Message Type 0001 (Vehicle Data Request) Figure 29: Example of Message Type 0002 (Result Data) Figure 30: Example of Message Type 0003 (Unsolicited Vehicle Data) Figure 31: Example of Message Type 9999 (Keep Alive) for Solicited Port Figure 32: Example of Message Type 9999 (Keep Alive) for Unsolicited Port Figure 33: Program/Project Form Figure 34: Equipment Description Form Figure 35: Data Description Form Figure 36: Data Recovery Procedures Form Revision Date: 07/25/11 Page 7 of 138 Revision: 2.4

8 Figure 37: Startup Form Figure 38: Requesting Machine ID (If Applicable) Form Figure 39: Requesting Vehicle Data (Message Type 0001) Form Figure 40: Test Result Data (Message Type 0002) Form Figure 41: Unsolicited Vehicle Data (Message Type 0003) Form Figure 42: Keep Alive Messages (Message Type 9999) Form Figure 43: Error Recovery for Request for Vehicle Data (Message Type 0001) Form Sheet 1 of Figure 44: Error Recovery for Request for Vehicle Data (Message Type 0001) Form Sheet 2 of Figure 45: Error Recovery for Sending Test Results to PFCS (Message Type 0002) Form Figure 46: Error Recovery for Recovery Unsolicited Data (Message Type 0003) Form Figure 47: Error Recovery for Keep Alive Messages (Message Type 9000) Form Figure 48: Miscellaneous Error Recovery Procedures Form Figure 49: Shutdown Form Figure 50: Integrated Testing Form Sheet 1 of Figure 51: Integrated Testing Form Sheet 2 of Figure 52: PFD Documentation Form Revision Date: 07/25/11 Page 8 of 138 Revision: 2.4

9 1.0 GENERAL 1.1 PURPOSE This document describes the protocols required for a supplier supplied Plant Floor Device (PFD) to communicate with the Plant Floor Communication Systems for all Chrysler - North American Operations plants. 1.2 SCOPE This section seeks to define the PFCS Device Categories and to give guidelines on the best method of connecting the device to PFCS. 1.3 USERS - Suppliers (e.g. OEMs, Integrators, Vendors) - Chrysler (e.g. Launch Engineers, Control Engineers, Process Engineers, Plant Information Technology Infrastructure ITI personnel, Manufacturing Systems Launch Management MSLM personnel) - Any individual and / or organization involved in the design and installation of control systems for Chrysler. 1.4 DEFINITIONS Use of Shall, May and Should The word shall is understood as a requirement. The word should is understood as a recommendation or preference. The word may is understood to specify a specification that is condition dependent. The designer or vendor may be required to justify a deviation from the standard, and may be required by an authorized Chrysler representative to make alterations so as to conform. Revision Date: 07/25/11 Page 9 of 138 Revision: 2.4

10 2.0 PFCS DEVICE CATEGORIES AND CERTIFICATION REQUIREMENT 2.1 CERTIFICATION REQUIREMENT All supplier devices expecting to communicate to Chrysler Plant Systems through PFCS will be required to complete the PFCS Protocol Certification Process, at a designated Chrysler facility, before the supplier equipment can be installed in the plant. There are three approaches for getting PFCS Certification for new devices or re-certification of existing devices: If the device is part of a plant launch, then the PFD communication requirements/issues need to be coordinated through a launch coordinator, a launch manager and/or an Integrator If the device is for existing production then the PFD communications requirements/issues need to be coordinated through a Plant ITI person If PFCS Certification Testing is needed for a new device that is not part of a launch nor to be brought into a plant running schedule production, then the supplier needs to get in touch with the PFCS Group and the PFCS group will contact all relevant parties Prior to initiating the PFCS Certification Process or Prior to integration of the device in plant floor, the Supplier must provide hardware specifications to the Plant ITI person or the Integrator working with the Plant ITI. The information to be provided must describe the device s Hardware Architecture and any unique requirements of the device. This information will be added to the Plant ITI sponsored Manufacturing Integration Review (MIR) Database. The MIR is used to coordinate all work efforts for the device with the appropriate Central Support Groups (Corporate ITI) and is the method of choice to document the implementation of a new device on the plant floor. The MIR must be successfully completed, before the device is allowed into production. The role of the Corporate PFCS group is to test and Certify Suppliers PFCS Protocol Communications based on available/provided information at the time of Protocol Certification. However, it is the responsibility of the Supplier, Process Engineers, Torque Controller Engineers, and Plant Personnel to review Process items/issues. The launch/integration MLSM Group has its own acceptance criteria and could specify other testing requirements, such as verification of test results/formats at the Supplier Site which should be fulfilled before the equipment gets shipped to the plant(s). The PFCS Protocol Certification Process is covered in Section 6.0 of this document 2.2 PFCS DEVICE CATEGORIES PFCS Devices fall into three general categories: Process Equipment, Multi-Spindle Devices, and Single Spindle Devices. Revision Date: 07/25/11 Page 10 of 138 Revision: 2.4

11 2.2.1 Process Equipment All process equipment will be Ethernet connected using the TCP/IP protocol Process equipment is described as a device with multi-function operation designed to perform a specific set of tasks. This may include torque, fluid fills, functional testing, sub-assembly, etc. Typical Characteristics of Process Equipment Include: o PC, PLC-5, CLx or custom processor based o o Typically fixed mounted not portable Download of vehicle data supported Multi-Spindle Torque Tools All multi-spindle torque tools will be Ethernet connected using the TCP/IP protocol Multi-spindle torque tools are described as devices incorporating multiple torque spindles to rundown several fasteners simultaneously Typical Characteristics of Multi-Spindle Torque Tools Include: o PC, PLC-5, CLx or custom processor based o o o Typically designed for a specific function Typically fixed mounted not portable Download of vehicle data supported Single Spindle Torque Tools Single spindle torque tools can be Ethernet or RS232 connected. Single spindle torque tools are described as devices incorporating a single nut-runner used to attach single or multiple fasteners. Typical Characteristics of Single Spindle Torque Tools Include: PC, PLC-5, CLx or custom processor based Typically a generic design. Tool can be used in several different functions Typically a hand held device Typically portable. Easily moved to other locations. Download of vehicle data supported Revision Date: 07/25/11 Page 11 of 138 Revision: 2.4

12 3.0 SUPPLIER COMMUNICATION 3.1 INTRODUCTION This document describes protocols required for a Supplier, supplied plant floor device (PFD) to communicate with the Plant Floor Communication System (PFCS). These protocols affect the two-way conversational link used to send and receive data between PFDs and PFCS. Supplier devices may be connected to PFCS using the following options: RS-232 Connecting (a single spindle torque tool) to a - Chrysler supplied terminal server using: Data format: 8 bit ASCII Speed: 9600 BPS Parity: None Stop Bits: 1 Flow Control: None Ethernet Connection between PFDs and PFCS using TCP/IP sockets Revision Date: 07/25/11 Page 12 of 138 Revision: 2.4

13 3.1.3 Data Flow Diagram RDC CICS MAINFRAME ROUTER PFCS UNIX AVI UNIX TERM SERVER RS232/423 QAS TNG TCP/IP SOCKETS PFD'S Figure 1: Data Flow Diagram As seen in the data flow diagram above, the major parts of the communication link between PFCS and the vendor system are: RDC-CICS: Regional Data center/cics regions in which Chrysler online applications reside for example, PFS, Broadcast and Receiving systems. MAINFRAME: Front-end processor required for MVS-TCP/IP. AVI: The AVI (Automatic Vehicle Identification) System is a custom Application on a UNIX platform that interfaces with other corporate computer systems to gather and report specific vehicle build and style information. This extensive vehicle information is maintained on a real-time basis within an in-plant database. AVI is also closely integrated with plant floor manufacturing machines, to which it delivers this vehicle data. AVI can also gather data from the plant floor. It may store this information in its in-plant database for download to other plant floor machines, and it may report the data to other corporate systems. The AVI system is supported by the APIC (Automatic Product Identification & Control) Systems Group. Revision Date: 07/25/11 Page 13 of 138 Revision: 2.4

14 Revision Date: 07/25/11 Page 14 of 138 Revision: 2.4

15 PFCS: PFCS (Plant Floor Communications System) is the corporate communication standard for all Chrysler Assembly plants in the U.S., Canada, Mexico, and Europe. The PFCS system utilizes a client/server architecture incorporating applications residing on an IBM Unix server at each plant location, and integrated applications on the corporate mainframe computers. All PFCS applications are developed and maintained by the PFCS team. The system is a critical component required to receive/collect quality data from tooling and process equipment, and deliver this data to upper level mainframe applications. In addition, the PFCS system supplies specific vehicle style and build information to floor devices, and outside just-in-time suppliers. PFCS is an integral requirement for torque monitoring, automated line stops, terminal sequencing, and error proofing. QAS TNG: The Quality Alert System The Next Generation (QAS TNG) is the corporate standard in the Continental US and Canada, for vehicle tracking on the plant floor on selected conveyors. The QAS TNG system uses a PLC emulation engine running (SoftLogix) on a Windows 2000 server that is industrial hardened and with tightly integrated redundant components and communicates with other systems Tracking Image Application (TI), Factory Information System (FIS), PFCS, and Automatic Vehicle Identification. Vehicles in a QAS line stop type station have the ability to stop the line if it is known that the vehicle has not passed specified operation requirements for that station. The second important concept of the QAS system is to reliably associate the vehicle in station with the correct tool/process data by sequencing vehicles on the plant floor based on tracking image received from floor PLC s. TERM-SRVR: A terminal server is a protocol converter, which converts from RS232 to Ethernet TCP/IP. PFD: Plant Floor Devices such as Torque Monitors, Pedal Pushers, Wheel Aligners, Pin Stampers, SPD suppliers, etc. 3.2 PFCS PROTOCOL OVERVIEW A Plant Floor Device (PFD) uses the PFCS Protocol to communicate with the PFCS System. The embedded message type in the PFCS Protocol Header is what PFCS uses to route the data message to the correct upper level system. The PFCS Protocol also uses an acknowledging method to tell the sending device that the message was received by PFCS. The inverse of this is also true; the PFD sends an acknowledgement of having received a message from PFCS. These transactions are often referred to as the ACK/NAK Protocol. The PFCS system is capable of sending and receiving data from a wide variety of plant floor devices. All PFCS Data will be Printable ASCII Characters. The rest of this section details the type of communication and gives a general description of each Result data from the PFD to the PFCS system: The PFD sends data to the PFCS system as each operation is completed or at the end of a specific cycle. The trigger used by the PFD to send the result data packet to the PFCS system is dependent upon the specific physical process within the plant. PFCS will never request the result data from the PFD. Revision Date: 07/25/11 Page 15 of 138 Revision: 2.4

16 Revision Date: 07/25/11 Page 16 of 138 Revision: 2.4

17 3.2.2 Vehicle build information sent from PFCS to the PFD: Some PFDs require specific vehicle build information in order to complete an operation. This information ultimately resides on the Broadcast System. The PFCS Protocol provides the mechanism for receiving or retrieving this information either as an unsolicited build information message or as a response to a solicited request. Unsolicited build information messages can be configured to trigger when: A vehicle reaches a specific point on the assembly line, or as the vehicle enters into a job station (QAS Triggered Style Download) The operator triggers a download using a PFS terminal (PFS Terminal Triggered Style Download) Broadcast triggers a message at a status point (Status Move) An AVI point sends vehicle ID message, vehicle update message or an index message. AVI System converts these messages to Terminal Sequencing TS messages. Solicited response build messages occur when the PFD does a solicited request to PFCS, which is passed on to Broadcast/AVI and then Broadcast/AVI responds with the vehicle build data message. This method is used as a backup method or a build data recovery method if Unsolicited Build data receive fails. With this error recovery in mind, it is preferred to have the PFD support both the Unsolicited and the Solicited methods of data downloads. Refer to Sections 5.1 and for more technical details. Revision Date: 07/25/11 Page 17 of 138 Revision: 2.4

18 3.2.3 Requests for Vehicle Data This section outlines the process of both generating a request and receiving the response. The general dataflow is outlined in Figure 2: Request for Vehicle Data. The dataflow starts with the PFD sending the request for data to PFCS. PFCS will forward the request to either the RDC/Broadcast System or to the AVI System. The receiving system will respond with a response packet that is then sent back to PFCS and is forwarded to the Plant Floor Device. The following sections look at the detail of the data message to and from PFCS. RDC/AVI PFCS PFD ACK1 3 4 REQ1 ACK1 1 2 REQ1 DAT1 5 8 ACK1 DAT1 6 7 ACK1 Time Figure 2: Request for Vehicle Data Sending Vehicle Data Request to PFCS The PFD sends a request to PFCS. The message packet sent to PFCS includes a header, request, and delimiter. PFCS validates the message and sends an ACK (acknowledgement) or a NAK (negative acknowledgement) to the PFD Receiving Vehicle Data from PFCS The ACK sent to the PFD indicates that the request was received and will be forwarded to the RDC or AVI application program for processing. At this point, the PFD must wait for a response to the request. After receiving the response data, the PFD must send either an ACK or a NAK, thereby completing the data transfer. PFDs must process ACK/NAKs as described in Section Revision Date: 07/25/11 Page 18 of 138 Revision: 2.4

19 3.2.6 Unsolicited Vehicle Data The Unsolicited Vehicle Data Download sent from the PFCS Server to the PFD. The PFD is expected to ACK or NAK to PFCS Server for the data in response to its business rules. Due to the potential interactions between a solicited request and an unsolicited download, the following rules have been developed: Receiving unsolicited vehicle build data requires the PFD to have a separate RS232 port or Ethernet socket connection to PFCS. It is common to receive unsolicited vehicle data for the vehicle entering into the station or in the station without the PFD having to maintain a local vehicle database. Process issues need to be considered during initial design/setup of these stations. The design must cover what to do if the current operation for a vehicle is not complete and PFD receives a new unsolicited message i.e., PFD might have to buffer new vehicle build information to be used after the current operation completes. There could be other process requirements such as to detect a new vehicle in the station with digital IO and link that IO to detect build data received or to clear the vehicle build data previously received when the current vehicle exits the station. If the PFD maintains a local vehicle database with build information then the PFD must manage the additions, updates, and deletions properly. If a PFD local database gets corrupted, then should accept a recovery download from the RDC/PFCS system. This mode is referred to as Recovery Mode. Due to the complexity of managing several PFD databases on the plant floor and the difficult task of keeping all the vehicle data up to date, the PFD local vehicle database method will only be used for specific processes. RDC/AVI PFCS PFD MSG1 1 MSG1 2 4 ACK1 3 ACK1 Time Figure 3: Unsolicited Vehicle Data Revision Date: 07/25/11 Page 19 of 138 Revision: 2.4

20 If an ACK is received by PFCS, communications will continue with the next message. Because this is sent unsolicited, the PFD must always be in the correct state to receive data. RDC/AVI PFCS PFD MSG2 1 MSG2 2 3 NAK2 MSG2 2 Time 4 ACK2 3 ACK2 Figure 4: Unsolicited Vehicle Data with NAK followed by an ACK If a NAK is received by PFCS, the message may be re-transmitted to the PFD (depending on the error code). This repeated transmission is intended as a means of guarding against garbled data on the link between PFCS and the PFD. PFCS programs would subsequently re-send the message packet to PFDs. If the NAK exceeds a configured limit, then PFCS will log an error, discard the packet, and transmit the next message to the PFD Sending Test Results to PFCS When a PFD has finished its operation, it must send the results of that operation up to PFCS. RDC/AVI PFCS PFD 1 Time ACK1 2 RES1 Figure 5: Sending Test Results to PFCS The PFD sends a result packet to PFCS. The packet includes a header, result(s), and a delimiter. PFCS validates the message and sends an ACK or a NAK to the PFD. Revision Date: 07/25/11 Page 20 of 138 Revision: 2.4

21 Revision Date: 07/25/11 Page 21 of 138 Revision: 2.4

22 3.3 MESSAGE STRUCTURES All PFCS data messages have the same structure. This section identifies the structure and format of data, responses sent from PFCS, and error types Headers, Data, and Delimiters for data Message The message structure is the same for all types of data messages. Messages are sent in the following format: Machine Id Sequence Number Number of bytes of data Data End of Message TM DATA UP TO 1024 BYTES<CR> ACK/ NAK Message Type Figure 6: Message Format Table 1: Message Format Section Byte Position Description 1 4 Machine ID e.g... TM ACK/NAK/<SPACES>, spaces indicate for a data message Header 8 13 Message Sequence Number Message Type e.g. (0001, 0002, 0003, ) Byte count of data in data area of message. Data 22 n Variable data area up to 1024 bytes of data n + 1 Message terminator. Carriage return x 0d Note: All data is in ASCII format. Revision Date: 07/25/11 Page 22 of 138 Revision: 2.4

23 3.3.2 ACK and NAK messages The ACK sent to the PFD by PFCS says the vendor request was received and will be processed. If the PFD is sending operations results, then it can continue. If the PFD is requesting data, then the PFD should wait for the response packet corresponding to the request. After receiving the response packet, the PFD must send either an acknowledgment (ACK) or a negative-acknowledgment (NAK). ACK and NAK messages are sent in the following format: Machine Id Sequence Number Error Code TM01 ACK D <CR> ACK/ NAK Message Type Figure 7: ACK and NAK Message Format Table 2: ACK and NAK Message Format Message Byte Position Description ACK/NAK 1-4 Machine ID e.g... TM ACK/NAK area 8-13 Message Sequence Number Echo of Message Type. 18 Error Code for ACK/NAK. 19 ACK/NAK record terminator. x 0d Note: All data is in ASCII format. Revision Date: 07/25/11 Page 23 of 138 Revision: 2.4

24 3.4 MACHINE ID Plant ITI will assign a unique 4 character Machine ID to be used by a PFD for all PFCS communication. This ID must be a configurable option on the controller. Simple torque or process operations will generally require one Machine ID per connection to PFCS (also called a single machine ID port), however, in more complex cases; multiple Machine IDs may need to communicate to PFCS on a single port (also called a multi-machine ID port). For a single machine ID port, the PFD can have a pre-configured machine ID or can obtain a machine ID from a NAK B message received in response to a startup message sent with a machine ID of ---- to PFCS. For a multi-machine ID port, the PFD machine IDs must be configurable. Some examples of tools using multiple Machine IDs on a single port are: Multi-channel torque controllers PFDs that act as a server for more than one tool on the plant floor Any process that requires multiple machine IDs Multiple Machine Requirements: The vendor must provide a configuration screen on the controller to individually set up each four-character machine ID One of the machine IDs on the port must be configured as the "main" machine ID. Plant ITI assigns which machine ID is to be the main machine ID. The main machine ID must be used to establish connections to PFCS, and send keep alive messages (message type 9999) If the device requires vehicle build data, the main machine ID is the only device able make requests for and receive vehicle data (message type 0001) The main machine ID can also send test results (message type 0002) to PFCS All machine IDs can send test results to PFCS PFCS can also accept keep-alive messages from all machine IDs, if required by the process. If operation requires unsolicited data download from PFCS (type 0003), it must receive this download on a separate port While waiting for vehicle data (type 0001) test results cannot be sent Due to the complexity of multiple machine IDs on a single port, it is important that Corporate and Plant ITM be involved in the process Below is a diagram of a typical multi-machine workcell. For illustrative purposes, examples of how the workcell handles certain situations are given. Revision Date: 07/25/11 Page 24 of 138 Revision: 2.4

25 Figure 8: Typical Multi Machine Workcell The workcell makes VIN specific requests (type 0001) using machine ID ET01, the main machine ID. PFCS ACK s these requests, returns the broadcast data to ET01 and ET01 sends ACK's to PFCS when the data is received. When sending test results (type 0002) from the Trim Area to PFCS, the workcell uses machine ID ET0T, and the actual tester ID (T1-T4) is sent as part of the test results When sending test results (type 0002) from the Final Area to PFCS, the workcell uses machine ID ET0F, and the actual tester ID (F1-F4) is sent as part of the test results When sending test results (type 0002) from the Repair Area to PFCS, the workcell uses machine ID ET0R, and the actual tester ID (A1-A4) is sent as part of the test results When sending test results (type 0002) from the Emission Area to PFCS, the workcell uses machine ID ET0E, and the actual tester ID (B1-B4) is sent as part of the test results Revision Date: 07/25/11 Page 25 of 138 Revision: 2.4

26 3.5 MESSAGE TYPES The following table describes the valid PFCS Message Types PFCS Message Type Table 3: Valid PFCS Message Types Description 0001 Request for vehicle data from server/host to PFD (i.e. get data from host). Requested data will also be returned from PFCS with this message type. No other message can be sent on the port while waiting for requested vehicle data Test Results to PFS from PFD 0004 Test Results to Broadcast from PFD 0006 Messages from ALSVS to PFCS 0003 Unsolicited vehicle data from server/host to PFD Keep alive message from PFDs. PFCS Message Types 0001, 0002, 0004, 0006 are Solicited Message Types and 0003 is an unsolicited Message Type. 3.6 CONNECTION TYPES/TWO PORT COMMUNICATIONS A PFD that intends to send solicited messages and receive unsolicited messages must establish two port connections to PFCS. This is called two port communications to PFCS and has the following characteristics: The port/connection which sends solicited messages is called the solicited port The port/connection which receives unsolicited messages is called the unsolicited port. Both the solicited and unsolicited ports shall send keep alive messages to PFCS. Implementation Notes concerning Two Port Communications: Any Process Equipment or Torque Monitoring Equipment supplier intending to receive vehicle build data information from RDC/PFCS must implement minimum a two port communications, with options to enable/disable each port s communication. At the time of initial integration of the device on the plant floor, Plant ITI/Plant Integrator will decide to enable or disable each port based on the station floor requirements. The number of solicited and unsolicited connections to PFCS are determined by supplier system capabilities/architecture and the floor processes that the supplier system supports. 3.7 CONNECTION STATUS DISPLAY A PFD must display the main machine ID for each port and the current PFD communication status to PFCS on the main display screen. Revision Date: 07/25/11 Page 26 of 138 Revision: 2.4

27 3.8 PFD LOGGING AND DEBUGGING MESSAGES The supplier shall log messages sent to and received from PFCS with time stamp. The time span of the logs, debugging messages to be written to the logs or be to be shown on display screen, and cleanup of logs are left to supplier discretion. For multi-port communications to PFCS, a separate log file should be kept for each port s communication. Revision Date: 07/25/11 Page 27 of 138 Revision: 2.4

28 3.9 DOCUMENTATION The supplier must provide information/relevant documentation details to the Integrator/Coordinator for inclusion with the MIR Process Documentation. The Supplier must also provide PFD documentation on all setup procedures, screen snapshots that relate to PFCS communications, and documentation on all error recovery procedures ENABLE/DISABLE COMMUNICATIONS AT PORT LEVEL Supplier software must support the ability to enable or disable communications at a port level. This functionality supports the following floor activities: When a device is no longer required to communicate to PFCS, the feature is useful to decommission device communications to PFCS. Provides the ability to enable/disable solicited & unsolicited communications based on floor process COLLISION PROCESSING A PFCS Protocol Message Collision is when PFCS tries to send an unsolicited message to the PFD at the same time the PFD is trying to send a different message (Solicited message or keep alive message) to PFCS. The impact of a PFCS Protocol Message Collision is an increased risk of a lost unsolicited message between PFCS and the PFD. The PFD supplier software must recognize the collision condition on the Unsolicited Port connection and must send an ACK/NAK to the received unsolicited collision message ERROR RECOVERY PROCESSING If either PFCS or a PFD detects an error, the error messages described in the table in Section are used to identify the error so that appropriate actions can be taken Error Description Table The following error codes are generated by PFCS and sent to the PFD to indicate possible errors in ACK/NAK records. Revision Date: 07/25/11 Page 28 of 138 Revision: 2.4

29 Table 4: Error Codes Possible In an ACK/NAK Record Sent With NAK ACK Error Code A Error Description Bad data received from PFD, message type not configured in PFCS, or data can not be processed by PFCS. Action to be taken by PFD Retry message as configured (default 3 times) at 5 sec. intervals. B Machine ID not valid. PFD must use the first four bytes from NAK as machine ID For a single machine ID Port, a NAK- B is sent in response to a whoami message which contains four dashes instead of a valid machine ID. E Sequence number not numeric. PFD should reset its sequence number to "000001" and re-send H Invalid message type. Correct message type and re-send. J Invalid byte count of data, must be in the range Correct data length and re-send. I Input exceeds 1024 bytes Reformat the message and re-send D Duplicate message sequence number. Process like ACK. Go to the next message. The following table describes the error codes that must be generated by the PFD when an error condition occurs. Table 5: Error Codes Generated by the PFD Sent With NAK ACK Error Code Error Description Action to be taken by PFCS A Bad data received from PFCS. PFCS will retry sending the data. (default 2 times) E Sequence number not numeric. PFCS will reset the sequence number to "000001" and re-send the message. H Invalid message type. PFCS will log NAK for use in error detection and alarm notification I Input exceeds 1024 bytes. PFCS will log NAK for use in error detection and alarm notification. F Unexpected sequence number PFCS will re-send the message using the sequence number given in the PFD's NAK. (default 2 times) J Invalid byte count, must be in the range PFCS will re-send the data. (default 2 times) D Duplicate message sequence number PFCS will process like ACK and send the next message. G Delayed data delivery PFCS will process like ACK Revision Date: 07/25/11 Page 29 of 138 Revision: 2.4

30 K Invalid Vehicle Data PFCS will process like ACK & log for use in error detection & alarm notification. U Unexpected Message Type Solicited Port receives unsolicited message type. Revision Date: 07/25/11 Page 30 of 138 Revision: 2.4

31 Implementation Notes: If the PFD receives data length greater than expected data length and receives valid data that the PFD is looking for, then the PFD sends an ACK (with no error code) to PFCS If the PFD receives data length equal to the expected data length and receives valid data that the PFD is looking for, then the PFD sends an ACK (with no error code) to PFCS If the PFD receives data length equal to expected data length and receives invalid data, then the PFD sends an ACK -K to PFCS If the PFD receives less data length than expected data length, then the PFD Sends an ACK- K to PFCS. If PFD receives a response NF (Not Found) for a request, then the PFD Sends an ACK-K to PFCS Duplicate messages Duplicate messages are detected using sequence numbers (bytes 8-13). If a PFD receives a duplicate from PFCS, it must send an ACK with error code D. PFCS will do the same if it receives a duplicate message from a PFD. Upon receipt of an ACK-D, the PFD should discard the message and continue processing Unrecognizable Characters If the PFD receives unrecognizable characters from PFCS (control characters, etc.) in any portion of the message, it should log an error and send a NAK-A message to PFCS Sequence Number Processing This section discusses the use of the PFCS sequence number for error detection and the actions to be taken by PFCS or the PFD to resolve or log the event General Message Sequence Number Rules General Message Sequence Number Rules for both the PFD and PFCS are as follows: A message sequence number will start at "000000" and will increment by one until the number "999999" is reached When the message sequence number reaches , the number will wraparound or reset to the number and continues as a normal sequence number from that point forward Message Sequence Number Rules for Solicited Port The PFD must maintain a separate message sequence number for each solicited port used in PFCS communications. For each new solicited message, that is not of the type KEEP ALIVE, the PFD increments the message sequence number. See Sections and Revision Date: 07/25/11 Page 31 of 138 Revision: 2.4

32 Message Sequence Number Rules for Unsolicited Port The PFD must maintain a separate message sequence number for each unsolicited port used in PFCS communications. PFCS increments the unsolicited sequence number when it receives an ACK from PFD and the PFD keeps track of the unsolicited sequence number received from PFCS. See Sections and Messages from PFD Rules governing the use of sequence numbers for message from a PFD to PFCS are as follows: If PFCS receives an unexpected sequence number from the PFD o PFCS will log the event into its transaction log o If no other problem is found with the message, PFCS will send an ACK to the PFD using the received sequence number If the connection from the PFD to PFCS terminates or restarts, the sequence number will be reset to "000000" for the port. For a PFD that requests Vehicle Build Data through PFCS (Message Type "0001") o If a PFD determines that it has a delayed response for vehicle build data, it must send an ACK-G message to PFCS o A delayed response is determined by the PFD either by message content or a request time-out cycle. See Section ( Time-out (Received ACK from PFCS and Waiting for Vehicle Data) Messages from PFCS Rules governing the use of sequence numbers for messages from PFCS to the PFD are as follows: A PFD must send a NAK with an error code of 'F' for any unexpected sequence number received from PFCS. A message sequence number is unexpected when the current sequence number is not equal to the previous sequence number plus one. PFCS will re-send the message with the expected sequence number taken from the NAK-F message If a PFD receives a type "0003" message with sequence number "000000", then the PFD's sequence number must be re-set to "000000" Time-out (Waiting for ACK) PFD equipment must time-out in N seconds (typically N=5 seconds) while waiting for an ACK/NAK from PFCS and retry the message up to 3 times. If all retries are unsuccessful, PFD should close the connection and reconnect. This is designed to handle lost messages between process equipment and PFCS. Note: The length of the time-out should be determined by the process cycle time and must be a configurable option in the PFD. Revision Date: 07/25/11 Page 32 of 138 Revision: 2.4

33 Revision Date: 07/25/11 Page 33 of 138 Revision: 2.4

34 Time-out (Received ACK from PFCS and Waiting for Vehicle Data) PFDs must time-out in N seconds (typically N=5 seconds) while waiting for a response to a request. The request must be logged and discarded. If the process option allows, a new request may be submitted to PFCS as long as the sequence number is incremented. Note: The length of the time-out should be determined by the process cycle time normally, the length of time before the PFD prompts the operator to manually perform the entire operation and must be a configurable option in the PFD Time to Connect (Reconnect Timer) The PFD tries to connect to a port on the PFCS server and connection from the PFD to the PFCS Port is not successful, then the PFD must wait N Seconds (typically N=20 Seconds) before it tries to connect to PFCS again. Note: The length of Time to Connect should be determined by the architecture of PFD communications to PFCS and how it reacts to PFCS server closing the connection etc Machine-ID Error The PFCS machine ID(s) must be a configurable option in the PFD. PFCS returns a NAK-B for any invalid Machine ID. The PFD must respond to this message in one of the following ways: If the PFD's process requires a single machine ID on its port, then the PFD can get the expected machine ID from a NAK-B by sending a whoami message (i.e., four dashes as its machine ID) in its first message after power up initialization. If the PFD's process requires multiple machine ID's on its port, then the PFD can get the expected machine ID from a NAK-B by sending a whoami message (i.e., four dashes as its machine ID) in its first message. This machine ID should be used as the tool's main machine ID (The main machine ID is the ID used for sending keep-alives and requesting vehicle data). If the PFD already has its main machine ID, and is not sending an whoami message, then the PFD should not change its machine ID as a result of NAK-B. It should just resend the message up to the configured number of retires (no delay between retries) and resume normal processing. Revision Date: 07/25/11 Page 34 of 138 Revision: 2.4

35 Keep Alive Message (backward compatibility format) All PFDs must send Keep Alive Messages at regular two minute intervals on each established connection to PFCS, whenever they are in an idle state (not sending or receiving messages). An ACK is sent by PFCS in response to the keep alive message to let the PFD know PFCS is alive If PFCS fails to respond to a keep alive message, then the PFD must go into its error recovery routine as defined in Sections (Error Recovery RS232) and (Error Recovery for TCP/IP Connection) This message is typically used to diagnose communication problems The sequence number of a Keep Alive Message for the port is the message sequence number of the last valid solicited message processed by PFCS Format: MMMM LLLLLL VENDORNAMODEL1V10001<CR> (1) (2) (3) (4) (5) (6) (7) (8) (9) (1) Machine-ID (4 bytes) (2) Blanks (3 bytes) (3) Last message sequence number processed (6 Bytes) (4) Request type, constant 9999 (5) Data length 20 (4 bytes) (6) Vendor Company Name (8 bytes) (7) Hardware Model (6 bytes) (8) PFCS Protocol Changes Version (6 bytes) (9) Message terminator carriage return (x 0d ) Revision Date: 07/25/11 Page 35 of 138 Revision: 2.4

36 Format: BF01 PFDs can send text messages using the Keep Alive Message structure. These messages are logged in PFCS in log files only and can be used for debugging/troubleshooting purposes. For example: VENDORNAMODEL1V10001Manual<CR> (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (1) Machine-ID (4 bytes) (2) Blanks (3 bytes) (3) Last message sequence number processed (6 Bytes) (4) Request type, constant 9999 (5) Data length 26 (4 bytes) (6) Vendor Name (8 bytes) (7) Hardware Model (6 bytes) (8) PFCS Protocol Changes Software Version (6 bytes) (9) Text message (Up to 50 bytes) (10) Message terminator carriage return (x 0d ) Keep Alive Message (new format) All PFDs must send Keep Alive Messages at regular two minute intervals on each established connection to PFCS, whenever they are in an idle state (not sending or receiving messages). An ACK is sent by PFCS in response to the keep alive message to let the PFD know PFCS is alive If PFCS fails to respond to a keep alive message, then the PFD must go into its error recovery routine as defined in Sections (Error Recovery RS232) and (Error Recovery for TCP/IP Connection) The sequence number of a Keep Alive Message for the Solicited port is the message sequence number of the last valid solicited message processed by PFCS. The sequence number of a Keep Alive Message for the Unsolicited port is the message sequence number of the last valid unsolicited message processed by PFD. This message is typically used to diagnose communication problems Revision Date: 07/25/11 Page 36 of 138 Revision: 2.4

37 Data Area Table 6: Error Keep Alive Message new format Start End Len Description Machine ID ACK/NAK area: Spaces Message Sequence Number Message Type: Data Byte Count (position 22 to the end, excluding Message Terminator) 8 8 byte Vendor Company Name 6 6 byte Model Number/Name byte PFCS Protocol Changes Version number followed by delimiter : 6+1 Maximum 6 byte DLL version number followed by delimiter :, if n/a applicable, just delimiter : 5+1 Maximum 5 byte Sol or Unsol followed by delimiter : 2+1 Maximum 2 byte Connection number followed by delimiter : 50+1 Text message upto 50 bytes, followed by a delimiter : if applicable. 1 Message Terminator: x 0d Note: New Keep Alive format helps in identifying potential issues at the time device integration on the plant floor SPD SUPPLIER INFORMATION When a vehicle passes through a broadcast station at frame, paint, and trim information about the parts needed for that vehicle is sent to the Sequenced Parts Delivery (SPD) system. SPD identifies the sequence in which parts must be shipped in containers so that parts are received in correct sequence on the plant floor. Revision Date: 07/25/11 Page 37 of 138 Revision: 2.4

38 SPD Message Format This table identifies the SPD record layout including record header Start End Len Table 7: SPD Record Layout Including Record Header Machine Id defined by Chrysler ACK/NAK area: Spaces Message Sequence Number Request Type: Data Byte Count:(Position 22 to the end, excluding <CR>) Record Identification BCST - Pay-As-Built and supplier on-line BCCS - Corporate Suppliers BCSB - Pay-As-Built only batch BCSS = Supplier only batch Model Year Plant Code VIN (last 6) Pay-As-Built Status Broadcast Status Supplier Number Operation Number Vehicle Order Number Numeric Broadcast Sequence Number Broadcast Date and Time (YYDDDHHMMSS) DDD Julian date Recovery Flag (Y, N or E = Error) Part Information - up to eight occurrences of the following can be included: part number (10) and usage count (02) Message Terminator: x 0d Note: All Data is in ASCII format. Revision Date: 07/25/11 Page 38 of 138 Revision: 2.4

39 SPD Hardware Requirements For primary communications between Chrysler systems and the supplier's systems, Chrysler will provide a 56kb digital frame relay circuit to the supplier's location and will terminate the circuit with a 56KB DSU and a multi-port Router. Chrysler will, in addition, provide two (2) dial-in modems. Modem 1 will be used for the Chrysler Network Control Center to dial in for diagnostics, configuration and to initiate manual dial backup if the Router is not configured for auto-dial backup (Auto-dial backup is the default configuration option). Modem 2 will be used by the Router to initiate dial backup; the router will maintain the dial connection using Modem 2 until the primary frame relay circuit is returned to service. The supplier is responsible for providing standard 115VAC power receptacles for the DSU, the Router, Modem 1, Modem 2 and at least 1 spare receptacle in the event Chrysler needs to use diagnostic equipment brought on-site at the supplier location. These five (5) power receptacles are the minimum power requirements for circuit connectivity. In addition, the supplier is required to provide two standard business dial up telephone lines for use by Modem 1 and Modem 2 above in the event that dial backup is required SPD is an asynchronous application and the supplier is responsible for providing a serial I/O port on their SPD system and a cable connecting to this port for receipt and acknowledgement of SPD data sent by Chrysler to the suppliers system. The software the suppliers use for this purpose must conform to the coding requirements as outlined in other sections of this document. The connecting cable provided by the supplier must terminate on the Chrysler end with a DB25 Male connector. The connector on the supplier's end must be of a type compatible with the supplier's serial I/O port. The cable must be wired as a straight through cable as the Router port will present a DCE interface to the supplier's system. The modems and the supplier's I/O serial port must be configured for: 8 data bits, no parity, 1 stop bit and the I/O serial port should be set to operate at 9600BPS. Flow control may be used on this connection. Chrysler supports Xon/Xoff flow control, if flow control is required. Table 8: Modem Configuration Data Format 8 bit ASCII Baud Rate 9600 BPS Parity None Stop Bits 1 Flow Control Xon/Xoff (if required) Revision Date: 07/25/11 Page 39 of 138 Revision: 2.4

40 3.14 PFCS CONNECTIVITY SPECIFICATIONS RS232 Device Connectivity All vendor devices intending to connect to Chrysler computer equipment for transferring data electronically using RS232 must fully conform to the industry standard for serial communications. This standard is defined by the EIA RS-232C serial interface specification and can be obtained from the EIA (Electronics Industries Association). The document is fairly large and contains protocols other than RS-232C. The RS-232C portion of the EIA standard can be broken down into two main parts. They are synchronous and asynchronous communications. This document will pertain only to the asynchronous communications portion of the EIA. Outlined here are the requirements for affecting a two-way asynchronous communications link with Chrysler machines. Note: This is in no way meant to displace or replace the EIA document as the ultimate source of information regarding RS-232C communications. Note: Chrysler will provide an RS-232 to RS-423 (RJ45) adapter to connect the CAT-5 cable drop to a PFD. This will enable extended cable length to a maximum of 500 feet. RNG DTR XMT GND GND RCV DCD N/A RNG DTR XMT GND RCV DSR DCD CTS RTS RJ-45 (RS-423) DB25 (RS-232) Figure 9: Connector Diagram The vendor must supply a serial port on their equipment for connection of the RS-232C cable to be used for data transfer. This port must present a 25-pin (DB25) female connector configured as DTE. Note: More than one port may be required on the vendor machine. In addition, Chrysler will supply the RS-232C connecting cable (s). The RS-232C communication specification for serial data transfer using DB25 signaling refers to a full-pinned RS-232C cable (a cable wired with 25 copper conducts). This document will concern itself only with those pins required for asynchronous transmission. The table in Section will describe these pins and their functions. Revision Date: 07/25/11 Page 40 of 138 Revision: 2.4