The transition from writing code to building models: the future of software development

The modern car is often referred to as a computer on wheels. And this is not far off the mark, with complex ADAS and hybridized powertrains requiring millions of lines of software code to keep them on the road.

To put this into context: A million lines of code, if printed, would be about 18,000 pages of text: That’s the equivalent of fourteen copies of the epic book, “War and Peace”. But if this sounds impressive, spare a thought for the software developers who produced 6.5 million lines of code to control the avionics and online support systems for the Boeing 787; or closer to home, imagine having to write the 100 million lines estimated to be packaged with Ford’s GT!

This growing complexity attributed to the rising number of functions and the increasing interaction between them, as well as increasing safety requirements is forcing software developers to look at alternatives to the traditional document based (Alternatively often referred to as hand-coded) development.

One option, model-based development (MBD), is a simulation-based mathematical and visual approach for the development of complex systems. MBD relies on the systematic use of models throughout the development process for design, analysis, simulation, automatic code generation and verification, and is widely used in aerospace and automotive applications.

Notwithstanding the advantages of adopting this methodology, there is a certain amount of reluctance to readily switch to this technique – largely because of the software developers’ reluctance to implement changes that may introduce bugs that could delay the project.

Moving from document-based software developmentto a model-based system

With many developers used to the traditional document based development it’s important that the transition is gradual so as not to create unexpected problems during the implementation.

The following four steps represent a gradual approach that developers can implement to safely move the project along while retaining control of the important development elements:

1. Cautious experimentation: It’s advisable to focus on one section of the project, such as a new fragment of an embedded system – and build a software behavior model to generate code. This one small change is low risk, requires minimal investment of time and will demonstrate that:

• High-quality code can be created without hand coding
• The code matches the behavior of the model 
• A model can be simulated to work out the bugs in the algorithm much more simply and with greater insight than dynamically testing C code on a desktop

2. Once the initial segment of code has been shown to work successfully the process can be extended to a system-level simulation by incorporating the code into the rest of the application.

3. With a system-level simulation, it is possible to perform system integration virtually and gain an early perspective of how the hardware and embedded software will behave. This is especially valuable if the hardware is in development and does not yet exist or is expensive to prototype.

4. Once the initial model-based development trial is successfully completed, the models can be extended to other areas of the project: Even without a full-scale model of the environment or algorithm, simulation allows tests to be conducted under various extreme operating conditions from which basic parameters can be derived for inclusion into the hardware design activity. Moreover, these models can be stored for later use to solve different design problems in future development projects.

To successfully switch from hand-coded/ document-based development to model-based development can be challenging so it’s recommended that developers stick with the basics: The benefit of MBD is the ability to create component and system models, use simulation to test and validate designs, and generate C code automatically for prototyping and testing.

Advanced tools and practices, such as modeling guidelines, automated compliance checks and requirements traceability should only be introduced once the developer or team is comfortable with the process.

[inlinead]

By following these simple steps, even a small engineering team can quickly realize the significant advantages enabled by MBD; including faster time to first demonstration, faster time to market with a high quality product, and expanded capacity for developing complex systems.

Understanding the concerns of developers when moving to MBD, RWTH Aachen University and Ford have recently developed Arttest, a tool designed specifically for testing model-based software. In carrying out the tests the tool uses a domain specific language, and offers different test evaluation methods for automated open and closed-loop testing and reactive testing. Moreover it’s capable of automatically executing the tests, evaluating the outputs and generating summary reports indicating passed tests and errors found.

But even though tools such as Arttest remove some uncertainty from the process the automotive industry has a long way to go before software developers are comfortable using MBD: At the MathWorks Automotive Conference in 2016, Volkswagen presented a slide showing that only 30% of all series projects were conducted with the aid of MBD:

• 25% with code generation
• 5% as a design tool

This low implementation rate is more about the cautious nature of the industry than it is about the efficacy of the process. The transition to MBD must be managed carefully, both to demonstrate short-term benefits and to establish a culture that enables the full realization of the theoretical benefits of the approach.

The question then is: How to implement model-based software development methods in an automotive environment where traditional hand-coding principles are entrenched in the company culture?

Introducing model-based software development methods into the traditional automotive company culture

As with any change that demands a paradigm shift it’s natural that developers and managers alike will resist the change if not implemented correctly: And key to this implementation is education, not only on how to effectively use MBD, but also when to use it.

Developers of the model-based design software suits Matlab and Simulink, Boston-based MathWorks, believe that educating OEMs and suppliers in the use of this powerful practice is crucial to meeting the future challenges the industry faces.

Quoting the changes to the emissions regulations due in 2020 Mathworks claims that in recalibrating the engine maps the model based simulation tools available from the company provide advanced computational algorithms for low emissions, which can shave months off of the development time required for hand-coding.

But in an environment, such as in India, where manual coding is still prevalent it requires a steep learning curve before software developers will be comfortable to forsake hand-coding for MBD.

To achieve this Mathworks is training students in faculties and academic institutions to create an awareness about the platform and its application in the industry. For the past 10 years 2000 colleges in India have been using Mathworks model-based tools in their automotive electronics labs, thus offering developers the opportunity to interact with model-based practices in a controlled setting.

But, while equipping developers with the skills to implement MBD in the execution of a project is vital, this knowledge is worthless if the company does not support the process, thus when considering the transition to MBD as a way of developing embedded computing systems, it is important to consider culture, tools, processes, organization, and strategy:

• First, an organization must establish a culture that values the development and use of models and simulation as a core engineering activity.
• Tools must be readily accessible and widely available to enable the productivity enhancements which MBD can realize.
• These tools must be used within the boundaries of defined processes: While companies have varying levels of discipline in the design process riven by culture, regulation, best practices and the latest trends, when adopting MBD, effective and consistent processes must be established.
• Traditional organizational models may need to be adapted or abandoned in favor of ones that support MBD workflows. Deliveries of work products between internal groups and the boundaries between designer and implementer get blurred with MBD, therefore, an effective organizational structure with visionary leadership is essential for successful implementation.
• The transition to MBD must be driven by a strategy with clearly defined goals and supporting metrics. There should be a logical sequence to the evolution, which will differ from organization to organization. The strategy should build upon current strengths and shore up weaknesses in the design process. Top management needs to understand the strategy and hold the engineering staff accountable to deliver against the plan.

Companies that persevere with the implementation of MBD, can reap the rewards and gain a competitive edge over those that, for whatever reason, are slow to adapt. And with the future of the car likely to be closely entwined with that of software development, manufacturers should orientate themselves around model-based development, sooner rather than later.