Powering an Automotive Engine Control Unit with Perforce
Here at Tula Technology, we develop fuel efficient technologies for gasoline powered automotive engines. We adopted Perforce over two years ago for source control of Dynamic Skip Fire (DSF) technology running on a coprocessor of the Engine Control Unit. During that time, we have used Perforce successfully on multiple automotive projects and it has been the key to our success in a complex development environment.
Multiple Software Development Environments
Automotive system development usually employs model based designs. Control algorithms are typically developed as Simulink models and validated. Code is then auto-generated from validated models and used in a production environment for components such as hardware microcontrollers of an Engine Control Unit. The system is tested using automation and calibration tools like Automation Desk or Control Desk.
The code and tools at Tula run on a combination of Windows and Linux platforms and Perforce cuts across tools, file formats and platforms, serving as a common solution for a heterogeneous computing environment. Support for the command line across platforms enables scripting, which in turn enables automation of runs and scheduling of tasks.
Agile Development on Production Software
Tula’s Software Team uses Agile development on production software with the code and tests from numerous developers integrated every three to four weeks. The development, mainline and release streams are used for development, integration, testing and release.
P4’s advanced ‘Merge Down Copy Up’ feature is used to merge code from multiple developers. Sometimes the generated code and Simulink model fall out of sync, thereby corrupting a stream. To prevent this, scripts invoked by Triggers perform checks whenever a checkin is initiated. Scripts diff MDL files of the Simulink model, by overriding the P4's default diff application with SimDiff.
WebCarLab – Tula’s Automated Test Environment
Tula’s in-house tool, WebCarLab, is used for automation of runs and scheduling of tests. It eliminates bottlenecks in accessing a limited and precious resource such as the HIL (Hardware In Loop) bench. With WebCarLab, engineers across multiple geographical locations can access the HIL Bench around the clock. This enables 100 percent usage of the Bench.
Perforce is at the heart of WebCarLab. WebCarLab runs on a standalone server and accesses P4 server over a network. The process of check out, build, run and saving results is fully automated. WebCarLab checks out from depots using a P4 Python API. The Control software, Embedded Software and tests reside in their own depots and are checked out in separate clients.
A configuration file from Perforce is also used to configure the target HIL Bench. The test is launched on the HIL Bench using a Web Interface and checkouts are kept in sync using common labels across all depots. A common label across all depots allows failures to be traced and easily reproduced. The figure below shows WebCarLab, P4 server and the HIL Bench Setup. Tests are launched on the HIL Bench and run on dSPACE MicroAutoBox II. The MicroAutoBox II communicates with the Tula DSF Coprocessor and the fire/no fire decision is passed onto the Engine Actuators.