Model management software challenges at automotive facility

A system integrator was tasked to dig through model management software and create a new system for an automotive plant using intelligence from PLCs and HMIs.

By Nikhil Niphadkar December 1, 2022

Courtesy: Patti Engineering

Learning Objectives

Lacking documentation of how things work, observing programmable logic controllers and human-machine interfaces can help update production models.
Updated code was applied to a pilot station, then the main line.

Updating production models using PLC, HMI insights

Updated project models were needed for several automotive production lines.
Lack of documentation required observation of PLCs and HMIs to create models, new code, and validate new models, tested then applied to the main line.

Introducing new production models is a regular occurrence in the automotive industry, but for a local transmission manufacturer, this change became a complicated process. The new subcomponent model required the production lines to use a longer model number. The existing model management software had a user-friendly front end, but the back end was full of hard-to-follow code and lacked descriptions or documentation. Several plant engineers had attempted to work through the code, but were unable to make any progress.

The manufacturer reached out to Patti Engineering, a system integrator, to dig through the black box software, decipher how it worked and determine the best approach to make the necessary updates.

Integration challenges: Complex code, no documentation

The model management system used only the first 13 characters to designate the transmission instead of the entire 15. The new models would now require all 15 characters, which affected several production lines.

An original equipment manufacturer (OEM) had written the management system software years ago and did not provide documentation on its functionality. The plant engineers had not progressed working through the complex layers of code and could not answer any questions about it. As it was written using instance data blocks, even a small change had the potential to break the code and take down a station. Special care was needed to keep the production process functioning, the reporting software accurate, and allow the station to accept the new model type.

Model manager on the HMI screen helped with project updates and updating code. Courtesy: Patti Engineering

This project required a lot of planning to coordinate the rollout of the new code. The changes affected all existing models. The most affected production area was the secondary line that worked with the subcomponent exclusively. Every station required the standard changes with significant updates for load in, load out, laser etching and camera verification stations. The main line also needed to be updated for the subcomponents to be loaded in successfully.

As production ran all week, the only time for testing and validation was on the weekend. Delaying production was not an option, so all changes had to be removed at the start of every week until the plant engineers validated all changes.

Solution and benefits: PLC, HMI observation

With no documentation, and limited information from the plant engineers about the proprietary software, the integration team had to plan an alternative approach. This entailed having an engineer onsite right away to observe the programmable logic controller (PLC) and human-machine interface (HMI) while production was running at the plant. This initial deep dive gave insight into what was driving the logic and specific areas the team needed to focus on.

Siemens Simatic manager view shows the types of blocks involved in the project. Courtesy: Patti Engineering

With the knowledge gained from the initial trip, the integrator began the offline development back in the office. Once the preliminary changes were made, they re-budgeted for another trip onsite to test the updates on one pilot station to verify their understanding of the code. This not only helped solidify the necessary changes for the pilot station, but for all stations on the secondary and main lines. The result was a smooth completion of the remaining offline development and onsite debugging.

During the onsite debugging, the integrator placed the updated code onto new memory cards. At the end of every weekend, they exchanged the memory cards and restarted the station to restart production.

Project results: Expanding model management to main line

The combination of originally unplanned trips greatly reduced the overall project risk and created a great baseline to ensure project success.

During the project, the integrator documented all the required changes they had made and then trained the plant engineers on the management system. Plant engineers used the notes to complete main line updates.

Multi-layer cascading of the code can be seen: The left side shows the call structure. The block that is opened is the main block that deals with the operation of the load station – FB1024. Every activity in the station (say operating a stop, operation of the barcode scanner, sending data to MPTS, etc.) was made into an instance and stored in the stat memory of the interface of the block. This caused the debugging to be extremely complicated and time-consuming. Courtesy: Patti Engineering

The integrator returned onsite when new code was launched in tandem with the main line. They watched alongside the plant team as the model management system successfully ran old and new parts.

Nikhil Niphadkar is senior controls engineer, Patti Engineering, a CFE Media and Technology content partner. Patti Engineering is a CSIA certified member. Edited by Chris Vavra, web content manager, CFE Media and Technology, cvavra@cfemedia.com.