5 biggest challenges in Model-Based Development and proposed solutions

Ivan Dynov

Car manufacturers and suppliers worldwide have worked over the years on improvements in the area of mechanics, quality requirements and logistics. However, the main differentiation factor between brands turned out to be the electronics area. Whereas areas such as power train and body had small product development cost increases over the years, the costs for the development of electronic systems has been tripled. 

One of the main challenges in today’s software development is the shortening of development cycles for the car and at the same time, an increate in software complexity and hence development time of software. On top of that, increasingly high safety requirements are put forward. 

To master these challenges, car manufacturers and suppliers conduct a paradigm change in the software development from hand-coded to model-based development (MBD). 

A model-based approach is pursued to enable a shift of focus of the development process on the early phases, supporting a function based rather than a code-based engineering of automotive systems. 

One of the main advantages of this approach is the ability to trace errors early on and thus save cost and time in the development process.

The introduction of MBD influences established development processes, required resources and thereby also the organizational structure. In addition, high investment costs for tools and for training of the employees are necessary.

Embedded controls designers require a way to effectively test functionality, identify defects, mitigate solutions, and verify software performance despite constrained development schedules and budgets. Model-based design can enable this process. All external interactions and internal operations of an embedded system are represented in model-based design. 

The model becomes the foundation of the development process, from requirements development through design, implementation, integration, testing, and verification. Ultimately, by supporting collaborative engineering and incremental design and test, an MBD workflow saves engineering organizations time and money, while improving the reliability and adaptability of the end product.

With all the advantages of a model-based development there are still numerous challenges which need to be overcome, in order to ensure substantial cost and time reduction. In this article we will review the five biggest challenges in MBD of automotive applications and propose some solutions currently available on the market. 

1. Increasing Complexity

The systems in the car are becoming ever more complex (one says that by 2025, the number of lines of code in a vehicle will surpass 100 Million) and hence the traditional, document oriented approach to developing systems and software is reaching its limits in efficiency. Many OEMs and Tier 1 suppliers have thus been applying MBD, in order to tackle the challenge of complexity. 

For example at Honda (R&D center Europe) MBD has been applied for a number of years now. We asked Antonello Ceravola, Principle Scientist, about his opinion: 

“The experience in creating the most complex systems showed that each phase of the development process introduces complexity and therefore needs MBD. Particularly for large systems, any small problem that would be hidden in a too complex phase has the potential to injure the whole system. Complexity should be managed from several different perspectives and not reduced to a single phase (for instance the pure coding phase). For instance, in the process of creating our MBD framework, we reached a stage where it was relatively easy to integrate large systems, but, as consequence, debugging became more complex. The introduction of a reporting system, able to list and keep track of the latest updated software parts of a system in a kind of news-journal style, gave us a boost in localizing bugs.”

Antonello Ceravola will address this issue as a speaker at the International Conference “Model-based Development for Complex Systems” in September 2017. 

2. Change management and adaptation to the new approach

As noted earlier, a MBD approach presents a fundamental paradigm shift in the way automotive functions and software are developed. Whereas in the past one started to code from the very beginning and document the results, in the new realm a model is designed using a modeling language such as SysML or UML which is then put into a model based environment. The code itself is automatically generated. 

The function developers are now required to create those models and communicate them to their colleagues from later stages of the process (such as testing experts). This is a fundamental mindset change for most people and is paired with resistance from being used to the conventional way of development. The nature of this challenge is not necessarily a technical one, but rather one of change management. 

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 ([5]):

  • 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

  • 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. 
  • 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.
  • 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.

3. Lack of a unique, widely accepted integrated approach to MBD

The development process of automotive electronics and software consists or a complex chain of steps involving different stakeholders and parts of the organization. The OEMs dictate the requirements on the electronics and control software, that is then developed by the suppliers in an isolated and parallel manner and finally integrated by the OEMs themselves. The complexity and multitude of parties involved, cause communication challenges and issues with interoperability.

A rigorous model-based virtual integration for automotive systems is needed. In [1], the authors summarized the challenges to achieve such an approach and proposed a solution. 

The challenges sketched in this work amounted to the following areas. On one hand, the need for formal specification and on the other hand, the complicated and ambiguous nature of a virtual integration using multiple modeling languages and models were described. 

Furthermore, the lack of formalized architecture modeling in the conventional design process, semantic dissimilarity between models and their inherent formalism for timing specification and limitations in tool support were emphasized.

To cope with these challenges, the authors in [1] proposed a formal model-based integration framework, based on formal timing specifications, a methodology for contract refinement and composition was developed and implemented using a co-modeling, integration and optimization approach at system level. To quote the authors ([1]): “The proposal aims at a better adoption of the framework by standardizing key timing and quantitative specification aspects, as well as a tool-independent and trustworthy composition framework using formal contracts.”

4. ISO26262 compliance and automated model verification

The functional safety standard ISO26262 is the corner stone of the development of any safety-critical system. Making a system ISO26262 compliant is a major challenge in of itself. Code generated within MBD is being deployed increasingly in safety-related and safety-critical automotive applications. To ensure quality and functional safety, models and generated software components should be subjected to a combination of quality assurance measures and compliance with safety standards must be demonstrated. Until now, the ensuring of ISO26262 compliance is a tedious process and is mostly done manually without an automated procedure that would reduce time and cost.

A significant contribution to developing safety-critical systems in a MBD context was achieved by the PICASSOS project ([3]). PICASSOS was a UK government funded program to improve the ability of automotive supply chains to develop demonstrably safe highly complex software-intensive systems cost effectively. 

This was executed by a consortium of three universities and five companies including an automotive OEM and suppliers. 

The key challenge of not having an automated verification procedure was solved in a certain context by utilizing formal methods. The technology was applied in the context of ISO26262 and the impact of this technology to inform key management decision on the costs, benefits and risks of applying this technology on live projects was measured and evaluated. 

A unified model based process incorporating SysML at the system level and using Simulink and Stateflow auto-coded into C at the software level was used. 

This new development approach was based on an ISO26262 compliant process already used by the commercial partners, modified using formal methods. 

A number of trials were undertaken comparing these two processes on Electric Vehicle based systems.

Dr. Peter Miller from Johnson Matthey Battery Systems, who represented one of the industrial partners in the project will present the results at the International Conference “Model-based Development of Complex Systems” in Berlin, September 2017. 

5. Model-based Testing

Testing at the model and code level is an important step in validating the software against various types of defects that may be introduced in the development process. Model based testing (MBT) methodology, paves a road towards automation of testing activities. Test generation is a computationally complex task, which requires efficient constraint solving techniques and some guidance from the test engineer when this task cannot be solved by a tool. At the same time, automatic tools can hardly substitute domain testing experts which can develop more effective tests or at least test fragments than any tool.

The other challenge in MBT experienced by major OEMs and Tier 1s is the gap between the expertise, mindset and way of communication of on one hand function developers and on the other hand testing experts. There is still no standardized approach to documenting models which can be understood equally well by both parties. This leads to communication challenges and having to go back and forth trying to understand the models and integrate them into the test environment. 

An example of model based testing is given in [2], where the authors developed an integration testing approach and applied it on a model of component-based composition of systems based upon the AUTOSAR standard. 

This method can be applied to testing integrated components of a highly complex system such as an ECM (engine control module). It was based on an existing approach to unit testing, using so-called mutations of operators or statements in the description of a unit. This method was then extended to integration testing. 

In order to integrate units, two aspects are considered: 1. Data Flow Integration and 2. Control Flow integration, where the former focuses on data flow relationships between the different units and the latter on the execution order of the units. Integration testing is then aimed at revealing errors in those two types of integrations. 

The main idea of this work was to define abstract methods for detecting mutants (which model the errors in the above flows) by generating a set of test data that help uncover these errors.

You can hear more about model-based testing in a presentation on MBT of automotive ECU’s from an OEM’s perspective by Ramesh S, PhD from General Motors at the International Conference “Model-based Development for Complex Systems” in September 2017 in Berlin. 


Model-based development of complex systems in the automotive domain is being widely adopted by the main players in the automotive industry. The advantages are numerous, especially due to the limitations of the traditional, document oriented approach for highly complex systems. There are still many challenges which are faced before a seamless model-based development can be applied. In this article, we sketched five of the main challenges and hinted at solutions that are already available in the industry. 


[1] “The Challenge of Interoperability: Model-Based Integration for Automotive Control Software”, Huafeng Yu, Prachi Joshi, Jean-Pierre Talpin, Sandeep Shukla, Shinichi Shiraishi, TOYOTA Info Technology Center, Virginia Tech, INRIA Rennes.

[2] Ramesh, S., Petrenko, A. and Nguena Timo, O. "Integration Testing of AUTOSAR Components" in Proc. of the 1st IEEE International Workshop on Automative Reliability & Test (ART 2016). Texas, USA, 17 to 18 November 2016

[3] Botham, J., Dhadyalla, G., Powell, A., Miller, P. et al., "PICASSOS – Practical Applications of Automated Formal Methods to Safety Related Automotive Systems," SAE Technical Paper 2017-01-0063, 2017, doi:10.4271/2017-01-0063

[4] “Improve Efficiency and Reliability of Complex Embedded Systems Development Using Model-Based Design”, Vince Socci, President Platform Division, LHP Engineering Solutions

[5] “The transition from writing code to building models: the future of software development”, Automotive-IQ article. https://www.automotive-iq.com/electrics-electronics/articles/transition-writing-code-building-models-future-software-development


Company information according to § 5 Telemediengesetz
IQPC Gesellschaft für Management Konferenzen mbH
Address: Friedrichstrasse 94, 10117 Berlin
Tel: 49 (0) 30 20 913 -274
Fax: 49 (0) 30 20 913 240
E-mail: info@iqpc.de
Registered at: Amtsgericht Charlottenburg, HRB 76720
VAT-Number: DE210454451
Management: Silke Klaudat, Richard A. Worden, Michael R. Worden

Firmeninformationen entsprechend § 5 Telemediengesetz
IQPC Gesellschaft für Management Konferenzen mbH
Adresse: Friedrichstrasse 94, 10117 Berlin
Telefonnummer: 030 20913 -274
Fax: 49 (0) 30 20 913 240
Email Adresse: info@iqpc.de
Registereintragungen: Amtsgericht Charlottenburg HRB 76720
Umsatzsteuer- Indentifikationsnummer DE210454451
Geschäftsführung: Silke Klaudat, Richard A. Worden, Michael R. Worden