chp6 vehicle management - ps.nafta.extra.fcagroup.com

System: AVI Title: AVI Training Manual Chapter 6: Vehicle Management

Owner: APICS of 22 Revision: 1.1

Document: Chp6 Vehicle Management.doc Revised: 2008 Feb 27

Automatic Vehicle Identification System (AVI)

Training Manual

Chapter 6: Vehicle Management




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




Document Revision History

Date Revision

Number

Name Description (include pages affected)

2008

Feb 27

1.1 Mas40 Change name to Chrysler

2007

Jan 09

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




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 2nd

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 (3rd

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.




PFCS

Mainframe PFS

& Broadcast

AVI

Work CellController

Plant FloorProcess PLCs

& Operator HMIs

Workstation PCAVI Client

Requests for product/vehicle information

and unsolicited updates

Reply to product/vehicle information requests and

unsolicited updates

Station 10

Station 30Station 40 Station 20

READER

Vehicle/productidentification

BarcodeReader

Requests for

product/vehicle information or update

(Multipacket)

Process equipment

product information

(Routing, Style, etc.)

Reply with

product/vehicle

information

(Multipacket)

Reply to information

requests, and subscription updates.

Requests for

information, database updates

and subscriptions

Requesting PLC

Figure 6-1: AVI Data Flow Diagram




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.

Figure 6-2: Vehicle Identification Message Route

READER

Bar Code Reader

Plant Floor Process PLC

& HMI

AVI Work Cell Controller (WCC)

Vehicle/product identification data

Vehicle/product identification message




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.

Figure 6-3: Data Request Get Specific Message Route

Bar Code Reader

Plant Floor Process

PLCs

AVI Work Cell

Controller (WCC)

READER

Requested data

Requesting PLC

(Point 3110)

Station 20 Station 10 Station 30 Station 40

Data Request “Get Specific” message

(Vehicle id, point #, template #, vehicle id

type)




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.

Figure 6-4: Data Request Processing Get Next

Bar Code Reader

Plant Floor Process

PLCs

AVI Work Cell

Controller (WCC)

READER

Response data on next

vehicle

Requesting PLC

(Point 3111)


Data Request “Get Next” message

(Vehicle id, point #, template #, vehicle id

type)




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.




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.

Figure 6-5: Index and Vehicle Update Messages

Plant Floor Process

PLCs


“Index”/“Vehicle Update” messages

Station 20 Station 10 Station 30 Station 40 READER




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.

Figure 6-6: Marriage

READER

Plant Floor Process

PLCs


Vehicle/product identification data

Marriage application accesses a VIN listing & creates a data

record of an association between the vehicle/product

identification number & the VIN.

Marriage complete response


Vehicle/product identification & Marriage

Request message

Marriage screens




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.

Figure 6-7: Unsolicited Data Response

AVI Supervisor

PLC

Station 20 Station 10 Station 30 Station 40 READER

Plant Floor Process

PLCs

AVI Work Cell Controller

Unsolicited Data Response message

Unsolicited Data Response message

Replying PLC

(could be any Station)

Acknowledgement or Requested Information

Acknowledgement or Requested Information




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.




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.

Resequenced vehicles after Colorwheel

Figure 6-8: Color Wheel Application

Body A VIN 10

– to be painted Red.

Body B VIN 12


Body C VIN 11

– to be painted Blue.

Body D VIN 13


Unpainted bodies entering paint shop.

Body A VIN 10


Body B VIN 11


Body C VIN 12


Body D VIN 13





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.




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

B

Lane 1

Lane 2

Lane 3

Lane 4

Lane 5

Lane L

Recirculation loop (optional)

Input

queue

A C D E F G

In transit

queue

Out transit

queue

Exit

queue

Post

queue

.

.

.

MDS

Entrance

MDS

Exit

Pre MDS

MD

S lo

ad

Sele

ct

in

Lan

e e

ntr

y

Sele

ct

ou

t

Lan

e e

xit

Exit

ban

k v

eri

fy

Lanes

Figure 6-9: Model System




Operation AVI Point Point Details

A Pre MDS

Conveyor infeeds merging, pull offs / insertions,

and MDS feeder advance point.

Pre-sequencing area run by OEM

logic

B MDS load

Feeds MDS vehicles. Requires positive veh id.

Pt #1 GS May use reader points in A if close

enough.

B-C Input queue

C Select in

AVI workcell MDS algorithm determines path.

Pt #2 Read /

GS / Index

Pt #3

Mixbank Req

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

C-D In transit queue

D Lane entry

Info used for MDS tracking

Pt #4 Index In AVI Index message, Index # =

Lane number (info used for OEM to

verify lane). Veh id from Pt #2

D-E Lanes

E Select out

AVI MDS workcell algorithm returns exiting

vehicle id

Pt #5

Mixbankb

Req

E-F Out transit queue

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 Exit queue

G 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

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

Table 6-1: Model System Sequence




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




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.




6.12.6 Mixbank User screens

See AVI Training Manual Chapter 7: Supervisory User Interface for more information.




6.12.7 Mixbank Options

In relating to Figure 6-9

Problem Description and fix

Bank high limit 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

Bank low limit 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 Empty carriers will be treated as golden units. A future option will be

created to treat them as non entities.

Unmarried label 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 Description and fix

Mismatch at entrance 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.

Mismatch at exit 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.

Missed index at entrance 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.

Missed index at exit 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.




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.

chp6 vehicle management - ps.nafta.extra.fcagroup.com

Documents