Before new vehicles leave the production line they undergo a series of end-of-line checks, including static and dynamic tests. In static tests, both technicians and automated test procedures run electronic diagnostics; in dynamic tests, technicians, testing software, a dynamometer, and other test stations work jointly to check the engine and adjust the suspension or other components.

Orchestrating and coordinating the workers, machines, and vehicles involved in end-of-line testing is a complex task. Many companies do not have a formal method for optimizing the process, instead relying on the subjective recommendations of senior engineers; on best practices from other manufacturing plants, which may have different requirements; or even on trial and error.

To maximize production throughput and capacity while minimizing manpower and waste, I developed a platform for running simulations with Simulink^® and SimEvents^®. The simulations are used to aid operational decision-making, forecast the outcomes of proposed manufacturing process changes, and improve the efficiency of Daimler production lines (Figure 1).

Challenges of End-of-Line Test Optimization

Several factors complicate the optimization of end-of-line testing. First, it is difficult to estimate processing times at any given test station. Variances in suspension, for example, mean that some vehicles require more time at the suspension adjustment station than others. Second, introducing new equipment that can complete tests faster can also disrupt established processes. Likewise, introducing new technologies into the vehicles results in new optional extras that require new test procedures.

Third, the sheer complexity of the process improvement options available makes it almost impossible even for an expert to predict how changes will affect overall process performance. Adding workers, completing tests in parallel, handling reworked cars, inserting buffers (queues) before each test station, permitting vehicles to cross between test stations, advancing the cycle time—the expert would need to understand the effect of every possible combination of these options to find the best configuration.

Gathering and Managing Data

I knew that my simulations would need to take into account an immense amount of data. Often in simulation studies, data is exchanged between disparate software packages, risking loss of precision and completeness. With MATLAB^® and Simulink, I use the same environment for collection, analysis, and preparation of data as for the optimizations and simulations based on that data. Plus, I can accelerate processing by running analyses on multiple computing cores with Parallel Computing Toolbox™.

Each test station generates a log file for each vehicle. If 1000 vehicles are tested at three test stations, then 3000 data sets are logged. For a single vehicle on one station, the log files contain up to 200,000 lines of information. Each log file contains only a small fraction of the necessary information, which includes vehicle details, the results of each test, and how long each test took to complete. To extract this data rapidly I create one DOS-based batch-file, call it for each log file, and distribute these jobs on each available core.

Analyzing the Existing Process

Before I developed the simulation, I needed to understand the current testing process. I collected the log files from every test station and analyzed the data numerically and graphically in MATLAB. I plotted histograms and bar graphs of testing times and vehicle variations, and performed statistical analysis to correlate these variables (Figure 2). I accelerated the parsing and processing of the log files by a factor of almost four by using Parallel Computing Toolbox to execute these tasks on a four-core processor.

After interactively exploring and analyzing the data, I created an interface in MATLAB to simplify common analysis tasks (Figure 3). I packaged the interface and the analysis functions I developed in MATLAB as a standalone Microsoft^® Windows^® application, PARSE (Process Analysis Routine for Site-overlapping Exploration). Created with MATLAB Compiler™, PARSE enables my colleagues at Daimler to explore end-of-line testing data without installing MATLAB. PARSE also provides the database for the following modeling and simulation.

Modeling End-of-Line Testing Processes

Most engineers create models for discrete-event simulations by linking together queue, server, entity, and other blocks from predefined libraries. The predefined elements in most simulation environments make it difficult to understand their fundamental functionality and their impact on the simulated system. I decided to take a different approach: I developed a MATLAB script to construct the SimEvents model programmatically. Building a model with SimEvents base-line elements has the advantage that all functional, logical, and strategical behaviors of the modeled system are known from the beginning. A programmatic approach makes it possible to run optimization algorithms that can both adjust model parameters and generate new models. It also enables models to be defined via a second interface that I built in MATLAB.

This interface enables engineers to define testing processes by specifying the number and configuration of test stations, the number of workers, and so on. The engineer’s selections are captured in a data model that the MATLAB script uses to generate a SimEvents model with station and worker subsystems (Figure 4).

In the generated model, which contains about 1500 blocks, worker and vehicle entities are brought together at each station with an entity combiner. The stations are represented by multiple single servers that represent individual processes within the station. The time spent at each station is calculated by an event-based random number block that uses an arbitrary discrete distribution based on the processed log data for that station.

Logical behaviors at the stations, as well as strategical control of the entities, are modeled using MATLAB scripts incorporated into the model as S-Function blocks. The model saves statistics from each station, including how many vehicles were processed, how long each vehicle spent at the station, and how much time it spent waiting between stations, as well as from peripheral processes such as delivery of vehicles, worker flow, and pause time. I used MATLAB to postprocess and visualize this data (Figure 5).

One of the first models I created using the interface and model generator simply replicated the existing factory setup with a database built on real-world raw data. I ran simulations of this model and compared its results with real-world results from the factory floor to validate the model and the model generation script.

Running Simulations to Optimize the Process

Once I had a way to process and analyze log data and programmatically generate models, I could begin running systematic simulations to optimize end-of-line testing performance. In the simulations, the optimization algorithms make structural changes to reflect different factory layouts as well as parameter changes on individual test stations. I provided boundaries and initial values and then applied a pattern search algorithm in Global Optimization Toolbox to optimize for factors such as throughput, required production equipment, manpower, and waste. It would take thousands of experiments to assess all possible model variants. I could achieve the same results with a fraction of this number using the pattern search algorithm.

The SimEvents models enabled me to adjust boundary values to run what-if scenarios. I ran simulations, for example, to see how vehicle variations affected the time required for specific tests, enabling me to identify the variations that most affect process performance.

Traditionally, automotive manufacturers have expended considerable effort on shortening test durations, with little awareness of how end-of-line layouts affect the overall process. At Daimler, my simulations studies changed this. The simulations and optimizations I conduct with SimEvents provide insights into the influence of changes in plant structure. Before designing a new manufacturing plant, Daimler can now evaluate how factors such as the size of the provision area and buffers, the number of stations, enabling junctions, and personnel will affect plant testing performance.