Automatic Vehicle Identification System (AVI) Training Manual

Automatic Vehicle Identification System (AVI) Training Manual Chapter 6: Vehicle Management Owner: APICS Page 1 of 22 Revision: 1.1

TABLE OF CONTENTS 6 VEHICLE MANAGEMENT...4 6.1 OVERVIEW...4 6.2 VEHICLE IDENTIFICATION...6 6.3 DATA REQUEST GET SPECIFIC (DRGS)...7 6.4 DATA REQUEST GET NEXT (DRGN)...8 6.5 DATA REQUEST SCHEDULE REQUEST (DRSR)...9 6.5.1 Scheduling...9 6.5.2 Schedule Request...9 6.6 INDEX...10 6.7 VEHICLE UPDATE...10 6.8 MARRIAGE...11 6.9 UNSOLICITED DATA RESPONSE...12 6.10 G STATUS...13 6.11 COLOR WHEEL...14 6.12 MIX BANK DECISION SYSTEM...15 6.12.1 Features & Benefits...15 6.12.2 Components...16 6.12.3 Mixbank point...16 6.12.4 Model system overview...16 6.12.5 System Details...18 6.12.6 Mixbank User screens...20 6.12.7 Mixbank Options...21 6.12.8 Mixbank Troubleshooting...21 6.13 CLONE...22 Owner: APICS Page 2 of 22 Revision: 1.1

Document Revision History Date 2008 Feb 27 2007 Jan 09 Revision Number Name Description (include pages affected) 1.1 Mas40 Change name to Chrysler 1.0 MAS40 2006 AVI Training Manual Update Project Supporting Documentation The Chrysler documents listed below are instrumental in defining this chapter's systems and its configuration. Doc. No. Rev. Date Title Link Owner: APICS Page 3 of 22 Revision: 1.1

6 VEHICLE MANAGEMENT 6.1 Overview The AVI system (Figure 6-1) consists of three layers of systems. Each layer represents a specific boundary of operations in the manufacturing process. 1. Plant floor controllers the 1st layer consists of the plant floor PLCs that control the product build process, and AVI Supervisor PLCs. The plant floor PLCs receive data from barcode readers and send the data to the AVI WCC. They provide the AVI WCC database file, ensuring that the database has the correct data at the correct time. 2. Work Cell Controllers (WCC) the 2 nd layer consists of WCC servers, located in the plant data center. The AVI WCC server is loaded with the following: a. The AVI applications (the outline of this chapter) and database b. PFCS communications application c. Intra application communication (known as COPA mail system) The AVI WCC receives messages and data from both the plant floor and the corporate computing computers. 3. Corporate computing controller (3 rd level) Broadcast (scheduling) and PFS (build data collection) systems, physically located at corporate data centers. They send and receive messages from the work cell controllers. Two types of messages are sent between components of the AVI system. Messages that require a response (request + response). Example is the plant floor controllers requesting from the AVI WCC what type of vehicle is in the station. Messages that do not require a response. (response only), referred as messages. Example is the plant floor controllers notifying to the AVI WCC that a vehicle has entered the station. A message that requires a response is sent to the application from which the response must come. The message includes all the data necessary for the application to retrieve the requested data and send it to the requesting location. Owner: APICS Page 4 of 22 Revision: 1.1

Mainframe PFS & Broadcast Reply to product/vehicle information requests and unsolicited updates PFCS Requests for product/vehicle information and unsolicited updates AVI Work Cell Controller Reply to information requests, and subscription updates. Reply with product/vehicle information (Multipacket) Requests for information, database updates and subscriptions Requests for product/vehicle information or update (Multipacket) Process equipment product information (Routing, Style, etc.) Workstation PC AVI Client Plant Floor Process PLCs & Operator HMIs Requesting PLC Station 40 Station 30 Station 20 Vehicle/product identification READER Barcode Reader Station 10 Figure 6-1: AVI Data Flow Diagram Owner: APICS Page 5 of 22 Revision: 1.1

6.2 Vehicle Identification A Vehicle Identification message (Figure 6-2) is a simple message coming from the floor to the AVI WCC. Other AVI applications can then access and use the data for tracking/visibility, and may use the information to trigger an event such as a status update to Broadcast or other vehicle updates. The Plant Floor Process PLC sends a Vehicle Identification message to the AVI WCC. The data included with the message comes from a barcode readers or manual input. The vehicle identification application simply places the data (which would be a barcode number or other vehicle/product identification method) into a specific location in the WCC database. AVI Work Cell Controller (WCC) Vehicle/product identification message Plant Floor Process PLC & HMI Vehicle/product identification data READE Bar Code Reader Figure 6-2: Vehicle Identification Message Route Owner: APICS Page 6 of 22 Revision: 1.1

6.3 Data Request Get Specific (DRGS) A data request Get Specific message (Figure 6-3) requires a response. This application allows the plant floor PLC to retrieve information for a vehicle located in the station it controls. In Figure 6-3, the PLC of point 3010 is requesting information about the vehicle in Station 10. Requested data may include build data (style, routing, history), additional identification information, process data (feedback, test setup), or other data. A DRGS is sent from the Process Equipment PLC to the WCC. For example, the PLC may need to know if the vehicle in the station is a Chrysler 300, Dodge Magnum, or Dodge Charger, so that the correct part can be loaded. The Data Request Get Specific application locates the requested vehicle in the database, and sends the needed data back to the Process Equipment PLC. The Get Specific request is also used to check for duplicate labels at the AVI Label verify point. AVI Work Cell Controller (WCC) Data Request Get Specific message (Vehicle id, point #, template #, vehicle id type) Requested data Plant Floor Process PLCs Requesting PLC (Point 3110) Station 40 Station 30 Bar Code Reader Station 20 READE Station 10 Figure 6-3: Data Request Get Specific Message Route Owner: APICS Page 7 of 22 Revision: 1.1

6.4 Data Request Get Next (DRGN) A data request Get Next message (Figure 6-4) requires a response. This message allows the plant floor PLC to retrieve information for a vehicle located in the station immediately upstream. In Figure 6-4, the PLC is sending a request using the vehicle currently in Station 20. The response will be on the vehicle in Station 10, the next vehicle. A typical use for this data would be to set up the station tooling before the vehicle arrives in station, saving cycle time. Note that the information about the vehicle in the upstream station must already exist in the database. One of the responsibilities of the Get Next application is to ensure that data for the vehicle in the previous station is up to date. Get Next data requests are used for sequence oriented processing. Plant floor systems that process vehicles in a predefined order use these requests. This application sends data about the "next" vehicle as requested by the floor PLC based on a sequence number for the current vehicle. AVI Work Cell Controller (WCC) Data Request Get Next message (Vehicle id, point #, template #, vehicle id type) Response data on next vehicle Plant Floor Process PLCs Requesting PLC (Point 3111) Station 40 Station 30 Bar Code Reader Station 20 READE Station 10 Figure 6-4: Data Request Processing Get Next Owner: APICS Page 8 of 22 Revision: 1.1

6.5 Data Request Schedule Request (DRSR) 6.5.1 Scheduling Scheduling is the process of determining the order in which parts or vehicles are built within the manufacturing plant. The basis of all BIW scheduling is the gateline sequence created by corporate systems. While it is desirable to build strictly in this gateline sequence, circumstances may dictate that to achieve the highest productivity or more efficient use of resources, it is necessary to deviate from this sequence. A shortage of parts or supplies may cause such a condition. 6.5.2 Schedule Request A data request Schedule Request message requires a response. Schedule Request is an application that enforces the gateline build sequence under ideal conditions, but allows controlled violation of that sequence when necessary. The application also provides for controlled recovery back to gateline when things return to normal. In this context, "controlled" means "adhering to necessary process constraints". The goal is to prevent loss of production due to gridlock, overproduction of a given style, or back to back release of a style beyond the capability of processes. Schedule Requests work similarly to DRGS data requests; however, the predefined order takes into account other factors, such as model type and species. Requests are made in sequential order within the different selection criteria. For instance, assume the gateline build sequence calls for the paint shop to produce three white vehicles, followed by three blue vehicles, followed by three red vehicles. However, the plant has run out of blue paint. The Schedule Request application would reschedule the blue vehicles. The application accesses the build sequence, finds the next vehicles to be painted an available color and pulls those vehicles forward in the schedule. When blue paint becomes available, the blue vehicles that were delayed are rescheduled as necessary to result in the proper number of blue vehicles being built. Owner: APICS Page 9 of 22 Revision: 1.1

6.6 Index An Index message (Figure 6-5) does not require a response. It is simply a message that updates the database to show that a vehicle has left a particular station. The data populating this portion of the database is typically used for statistical analysis. 6.7 Vehicle Update A Vehicle Update message (Figure 6-5) also does not require a response. It is simply a message that updates the database for a particular vehicle along with data. For instance, a vehicle update message may update the database to indicate that an operation has been completed successfully (or not completed successfully, requiring a repair when the vehicle reaches the appropriate repair station). The data populating the vehicle database would typically be used by other (AVI or PFCS) applications for statistical analysis. AVI Work Cell Controller (WCC) Index / Vehicle Update messages Plant Floor Process PLCs Station 40 Station 30 Station 20 READE Station 10 Figure 6-5: Index and Vehicle Update Messages Owner: APICS Page 10 of 22 Revision: 1.1

6.8 Marriage A Marriage request (Figure 6-6) requires a response. Marriage is the logical association of the identification value of a physical object with a data record. The identification value is the value derived from a bar-code label, RF tag, or similar device. To provide access to the vehicle data at some future location based on the detection of the label. To associate the components (e.g. sub-assemblies) with the vehicle for reporting and/or control purposes. The Marriage Station is the point where the vehicle is married to the VIN. Two types of marriages may occur during the vehicle assembly process. Soft Marriage: Associates a scheduled vehicle with a bar code label and a VIN. Vehicle VIN may be changed before T/C/F with only a soft marriage. Hard Marriage: A VIN is permanently assigned to the body at this point. Some plants only have a final Marriage Station. AVI Work Cell Controller (WCC) Marriage application accesses a VIN listing & creates a data record of an association between the vehicle/product identification number & the VIN. Vehicle/product identification & Marriage Request message Marriage complete response Plant Floor Process PLCs Marriage screens Vehicle/product identification data Station 40 Station 30 Station 20 Station 10 READE Figure 6-6: Marriage Owner: APICS Page 11 of 22 Revision: 1.1

6.9 Unsolicited Data Response The WCC sends unsolicited Data Request Get Specific messages (Figure 6-7) (without a request from the process equipment PLC). This type of message is sent when the WCC needs to locate a vehicle or for stations that may require advance notice that a vehicle is arriving. The process equipment PLC at the point replies with an acknowledgement that it received the data download or with the requested information. AVI Work Cell Controller Unsolicited Data Response message Acknowledgement or Requested Information AVI Supervisor PLC Unsolicited Data Response message Acknowledgement or Requested Information Plant Floor Process PLCs Replying PLC (could be any Station) Station 40 Station 30 Station 20 READE Station 10 Figure 6-7: Unsolicited Data Response Owner: APICS Page 12 of 22 Revision: 1.1

6.10 G Status G Status is a status that must be assigned to a body before it enters the paint shop. It can only be assigned when all WCC database entries are complete and quality requirements are met. In other words, the body must be identified (an ID message received), Get Specific, Status Update, Index, and all quality requirements must be met. Owner: APICS Page 13 of 22 Revision: 1.1

6.11 Color Wheel Color wheel is an application initiated by broadcast. The application improves the efficiency of the paint process by reducing the number of flushes (to change color) that must be performed in the paint booths. It does this by creating blocks of car bodies to be painted the same color. As unpainted bodies enter the paint shop, the colors they are to be painted is in a random order. The information about what color each body is to be painted is contained in the WCC database. However, except for differences within a style (e.g. a sunroof), the unpainted bodies are identical. The color wheel application can accomplish its function two ways. One, it interfaces with the conveyor system to direct bodies to a particular paint booth (there are typically several paths, through different paint booths, that a body may take). Two, within style constraints, the application can rearrange the vehicle sequence by divorcing and re-marrying VIN and barcode data as necessary to create block of same color vehicles. The example in (Resequenced vehicles after Colorwheel Figure 6-8) shows how this is accomplished. When the color wheel application sees body D enter the paint shop, it recognizes that, provided the styles are identical, two blocks of same colored vehicles, 1 red, and 1 blue, can be created. The application divorces VIN 11 from body B and VIN 12 from body C. Then marries VIN 12 to body B and VIN 11 to body C. As a result, body B will now be painted red, and body C will be painted blue. Note that as long as the body styles are identical, the same vehicles are manufactured, but fewer flushes to change color are necessary. Body D VIN 13 to be painted Blue. Body C VIN 12 to be painted Red. Body B VIN 11 to be painted Blue. Body A VIN 10 to be painted Red. Unpainted bodies entering paint shop. Body D VIN 13 to be painted Blue. Body C VIN 11 to be painted Blue. Body B VIN 12 to be painted Red. Body A VIN 10 to be painted Red. Resequenced vehicles after Colorwheel Figure 6-8: Color Wheel Application Owner: APICS Page 14 of 22 Revision: 1.1

6.12 Mix Bank Decision System The Mixbank Decision System (MDS) is an application that manages a plant selectivity bank where a defined product delivery mix is desired. An optimal product delivery mix will permit more efficient downstream station operations. An example would be to space out sunroof option vehicles in order to give more lead time for the sunroof installers to prepare for each vehicle. The system is a selectivity bank application that uses the MDS for the routing algorithm, AVI for vehicle identification and verification, and plant floor controls for providing information and events. 6.12.1 Features & Benefits Standardize on a corporate method to effectively operate selectivity banks. Reduce the need to expand existing and selectivity banks when a vehicle s option content/build complexity is increased. Reduce line stoppages due to over-cycles in high work content stations. Improve operator efficiencies by normalizing work requirements over many vehicles Improve reporting of algorithm techniques (example - to show rule violation numbers) using FIS historical reports Show real-time visibility and reporting of operations using a combination of operator terminals, paging, FIS and APICS Mercury Permit more vehicles to be released from previous shop and use the selectivity bank more efficiently. Owner: APICS Page 15 of 22 Revision: 1.1

6.12.2 Components The system is an integration of: Eight AVI points (2 to 3 have AVI readers) to identify vehicles and to serve events for a basic setup of MDS. Existing readers are used where possible. Floor control hardware: conveyors (lanes), PLCs, bar code readers, limit switches and operator interfaces (example - PanelViews). Mixbank Decision System (MDS) software residing in the AVI Workcell. Vehicle area tracking user interface (APICS Mercury's Mixbank screens). The application allow to view the vehicles in the selectivity bank, to configure input algorithm rules and to make corrections to vehicle placements. 6.12.3 Mixbank point A new AVI message type is introduced: Mixbank Request (AVI type 16 message) - Similar to a Get Next request except the vehicle id (a seed value) will be set to zero (0000 0000) on the request to the AVI Workcell. The AVI Workcell returns a response with the corresponding vehicle id and lane assignment. 6.12.4 Model system overview Pre MDS MDS load Input queue Select in In transit queue Lane entry Lanes Select out Out transit queue Lane exit Exit queue Exit bank verify Post queue MDS Entrance Lane 1 Lane 2 MDS Exit Lane 3 A B C D E F G Lane 4 Lane 5... Lane L Recirculation loop (optional) Figure 6-9: Model System Owner: APICS Page 16 of 22 Revision: 1.1

A B B-C C C-D D D-E E E-F Operation AVI Point Point Details Pre MDS Conveyor infeeds merging, pull offs / insertions, and MDS feeder advance point. MDS load Feeds MDS vehicles. Requires positive veh id. Input queue Select in AVI workcell MDS algorithm determines path. In transit queue Lane entry Info used for MDS tracking Lanes Select out AVI MDS workcell algorithm returns exiting vehicle id Out transit queue Pt #1 GS Pt #2 Read / GS / Index Pt #3 Mixbank Req Pre-sequencing area run by OEM logic May use reader points in A if close enough. Pt #2 barcode read. No GS - Pt #3 Mixbank Req obtains MDS veh id & lane. Compare with barcode. - If mismatch, Pt#2 does GS, and Pt #3 another Mixbank Req - Pt #2 Index Pt #4 Index In AVI Index message, Index # = Lane number (info used for OEM to verify lane). Veh id from Pt #2 Pt #5 Mixbankb Req F Lane exit Pt #6 Index In AVI Index message, Index # = Lane number (info used for OEM to verify lane). Veh id from Pt #5 F-G G Exit queue Exit bank verify Check that MDS made routing decisions on the correct vehicle. If installed, has option to recirculate the vehicle back to Mixbank entrance Pt #7 Read / Index Pt #8 Mb Req Table 6-1: Model System Sequence Pt #7 barcode read. No GS - Pt #8 Mb Req obtains MDS veh id. Compare with barcode. - If mismatch, fix with Mercury - Pt #7 Index Owner: APICS Page 17 of 22 Revision: 1.1

6.12.5 System Details MDS requires routing control of vehicles at both the entry and exit of the selectivity bank. A step by step walkthrough is as follows (in relating to Figure 6-9) 6.12.5.1 Pre MDS - A Ahead of the MDS, an assortment of optional activity happens: Merging vehicles from various conveyor infeeds Providing the last possible area for pull off and inserts Serving as a MDS feeder advance point. Optional conveyor infeeds merge to form a single entrance to the MDS system. Each infeed merge lane exit is required to have an AVI reader. The decision making process at this location should remain intact when an MDS system is implemented. Future MDS capabilities may assume control of this decision making. This will be the last opportunity for pull offs and inserts as the MDS requires a contiguous sequence of vehicles. An additional AVI reader and point will be required if pull offs / inserts are used to assure correct identification. This location can also serve as a feeder advance point. This point would allow the entry point of feeding vehicles to MDS have advance notice of vehicles coming in for further optimization in MDS. 6.12.5.2 MDS Load - B This is the beginning of the MDS which starts the MDS input queue. All jobs in the input queue are known and are used by the MDS algorithm for planning of the output lane sequence order. Vehicles entering the Mixbank system need to have positive identification. The purpose of the AVI GS point (MDS AVI Point #1) is to prefeed the MDS which better enhances algorithm execution. At this location, the vehicle is release by the control of the AVI Workcell. The vehicle id in MDS AVI Point #1 can be provided from an established reader point from the previous section if the reader point is close enough and can be assured integrity of the vehicle order. 6.12.5.3 Select In - C Here, the MDS algorithm chooses the lane for the vehicle. The first AVI point (MDS AVI Point #2) requires a reader. The AVI point serves as a reader point, Get Specific request and an Index request. A second AVI point, Mixbank Request (MDS AVI Point #3), is used to obtain the MDS vehicle id and lane number. The vehicle first enters MDS AVI Point #2, and here the barcode is read by the AVI reader. Then the MDS AVI Point #3 performs a Mixbank Request to get the vehicle id and lane assignment from MDS. The vehicle ids from these two operations are compared (using AVI GS / GN logic). If there exists a mismatch, MDS AVI Point #2 sends up a GS request with the actual barcode and the MDS adjusts to the new vehicle id and sends back a GS response. The floor then sends up a second Mixbank Request form MDS point #3 mainly to get the new lane assignment. As the vehicle leaves Select In, MDS AVI Point #2 sends up an index Owner: APICS Page 18 of 22 Revision: 1.1

message (with index = 1) to move the vehicle data from MDS Input Queue to MDS In-Transit Queue. The vehicle id of MDS AVI Point #2 is used as the vehicle id for MDS AVI Point #4. 6.12.5.4 Lane Entry - D The vehicles exit the input transit queue and into their MDS decided lane. The MDS is updated of the lane number entry via an AVI index message (MDS AVI Point #4) and the vehicle id is supplied from MDS AVI Point #2. The index number in the AVI Index message is set to the lane number of the vehicle entry. The number and capacity of each lane is dependent on the plant conveyor layout and vehicle build requirements and can be configured in APICS Mercury Mixbank configuration screens. 6.12.5.5 Select Out - E A request to MDS determines vehicle release lane. This is done by an AVI Mixbank Request (MDS AVI Point #5). The returned vehicle id serves as the vehicle for the upcoming lane exit MDS AVI Point #6 request. The vehicle ids are validated when they get to the Bank Exit verify location. 6.12.5.6 Lane Exit - F MDS requires a vehicle id and a lane number to move the vehicle data from Lane to Output Transit queue. An AVI index (MDS AVI Point #6) is used where the index number in the AVI Index message equals the lane number. 6.12.5.7 Bank Exit Verify - G At this location, the vehicle ids are validated with actual to that what the conveyor bank has released. An AVI reader is required (if there is a downstream reader in close proximity, it may be used (example would be Broadcast G-Status) and where the vehicles are contiguous). Two AVI points are used. The first is a reader point (MDS AVI Point #7) to read the bar code. The second is an AVI Mixbank Request (MDS AVI Point #8) and it gets a vehicle id back from MDS. The two vehicle ids are compared to verify that the release decisions are being made for the correct vehicle. A mismatch creates a fault annunciation along with stopping the conveyor allowing the image of the conveyor bank to be corrected. Upon leaving Bank Exit Verify, MDS AVI Point #7 sends an index message to move the vehicle from Exit Queue to Post Queue At the Bank Exit Verify point, the MDS algorithm can route the vehicles back to the beginning of the system via the recirculation loop. This is a future enhancement of the MDS algorithm. The existence of a recirculation loop is optional. Owner: APICS Page 19 of 22 Revision: 1.1

6.12.6 Mixbank User screens See AVI Training Manual Chapter 7: Supervisory User Interface for more information. Owner: APICS Page 20 of 22 Revision: 1.1

6.12.7 Mixbank Options In relating to Figure 6-9 Problem Bank high limit Bank low limit Empty carriers Unmarried label Description and fix At Select In (C), MDS on the AVI Mixbank Get Next point (MDS Point #3) can respond with data that the Bank is full such that adding more vehicles would hamper the algorithm. An FIS alarm is turned on and feeder conveyor into the bank is stopped. The floor controls will continuously and automatically request the Mb Req message until MDS responds back that free space is available again in the bank. The bank max vehicle value can be configured in APICS Mercury At Select Out (E), MDS on the AVI Mixbank Req (MDS Point #5), can respond with data that Bank is low (requires x number of vehicles in the system to keep the algorithm in tact). An FIS alarm is turned on and the output conveyor after the bank is stopped. The floor controls will continuously and automatically request the Get Next message until MDS responds back that there are sufficient vehicles again in the bank. The bank low limit vehicle value can be configured in APICS Mercury. Empty carriers will be treated as golden units. A future option will be created to treat them as non entities. Use of scrap functionality to route vehicle into MDS so that correct options for release. This is accomplished via the creation and deletion of clones. 6.12.8 Mixbank Troubleshooting In relating to Figure 6-9 Problem Mismatch at entrance Mismatch at exit Missed index at entrance Missed index at exit Description and fix At Select In (C), there is a disagreement of the read barcode and the Mb Req vehicles ids at the floor. This is done to verify the vehicles arriving into the bank so correct routing decisions can be made. An FIS alarm and a PanelView fault trigger are turned on. To clear the problem, the operation automatically corrects by the first point in the station (AVI MDS Point #2) triggering a GS, and MDS accepts the vehicle id in this message to be the accepted id. At Bank Exit Verify (G), there is a disagreement of the barcode read and the Mb Req vehicles ids at the floor. This operation is to verify the vehicles leaving the bank are correct. An FIS alarm and a PanelView fault trigger are turned on. Also the conveyor stops. Manual operation is required to validate the correct vehicle. To clear the problem, vehicles are to be verified and fixed on the APICS Mercury screen (Queue management). Upon solving the problem, the conveyor can resume via floor controls. At Lane Entry (D), a missed index message to MDS won't be detected until the next vehicle is to leave Select In (C). See description text of Mismatch at Entrance. At Lane Exit (F), a missed index message to MDS won't be detected until at Bank Exit Verify (G). See description text of Mismatch at Exit. Owner: APICS Page 21 of 22 Revision: 1.1

6.13 Clone Clone is an application with several uses. For instance, assume a body is pulled off the line at some point due to a quality concern or for a quality check. The body may need repair or the quality check may require weld testing that destroys the body. The vehicle is still scheduled for build, but is no longer in process. The clone application can be used to initiate production of a new identical body. However, as the new body progresses down the assembly line, it is identified as a clone. When it reaches the station where the old body was removed, the data is married to the new body and production continues. Another use of the application is to initiate production of an unscheduled body that will be pulled from the line at a certain point for testing or analysis. Owner: APICS Page 22 of 22 Revision: 1.1