Model-based development (MBD) has revolutionized how embedded software is designed, implemented, tested, and maintained. Modern-day cars have over 100 million lines of source code in the ECU, enabling advanced features like adaptive cruise control, lane changing, automated parking, and infotainment. The transition from handwriting code to generating code using models can be a great way to cope with the growing complexity and the need for more sophisticated, safe, and advanced features.
This blog article explores and summarises 3 of the many best practices in Model-based development for embedded software development highlighting the data management during the development process to ensure uniformness through the development team, hierarchical development and testing, and the need for requirements-based testing-driven development.
1. Streamlining Data Management - Data Dictionary
During the initial phases of Model-based development (MBD), data organization and standardization may be absent due to unknown model interfaces. As model complexity grows, managing different data elements can be difficult. As the system and model configuration requirements are defined in the early stages of the V-cycle, it is highly advisable to start streamlining the data using a data dictionary.
A data dictionary in model-based development is a centralized repository that defines data elements, which are used within a model. It serves as a guide that captures the metadata, attributes, relationships between various elements, and constraints associated with each element. Any changes made in a data element in the data dictionary will be reflected in all models and model elements that are referencing it. This minimizes customizations and helps in reducing the maintenance of models.
Projects can ensure consistent and standardized data representation across all developers by implementing a data dictionary. It also facilitates data-driven analysis and design by providing a comprehensive view of the system’s data elements, enabling users to identify data dependencies without analyzing the entire model.
2. Know your "Unit" and its Hierarchy
In Model-based development, a “Unit” refers to a specific part or module of the system that is being developed. Such as a sub-model, subsystem, or logic-based combination of blocks. These units play a crucial role in modularising and organizing the model. This makes it easier to comprehend, develop, and manage system complexity. Each unit can be designed and developed independently, allowing for parallel development and easier collaboration between multiple teams.
The concept of “Hierarchy” becomes essential when dealing with complex models. In model-based development, a hierarchy refers to the structure of models or components within a model or a system. It offers a way of breaking down a complex model into smaller, more manageable parts, which are “units”. The hierarchy also establishes relationships between these units. This hierarchical structure allows the developers to encapsulate the subsystems based on the unit’s functionality. These units represent specific parts of the model’s logic and as time progresses, they contribute to reusability and scalability across different projects.
Here is an example of how a unit and its hierarchy can be used in different ways in model-based development, depending upon the usage,
- Top Subsystem: The schedule layer is positioned at the top. This method makes integration with the code easy, but functions are divided, and the readability of the model is impaired.
Bottom Subsystem: Function layers are arranged at the top and schedule layers are positioned below the individual function layers.
3. Requirements and Test Driven Development
In Model-based development, Requirements-based test-driven development uses requirements as the foundation for model design and test execution during development. This process integrates requirements, models, and tests to ensure the developed system meets specifications. Tests are developed concurrently with models to verify and validate them, serving as a reference. By directly linking tests to requirements, this approach ensures the system adheres to specified behavior.
The requirements-based test-driven approach enhances communication and collaboration among the stakeholders of the project. This type of development is a perfect example of iterative and incremental development.
However, one might wonder, Can we use models as requirements?
It is important to examine the standards, such as ASPICE and ISO26262 when considering whether models can replace requirements.
The ASPICE standard emphasizes the importance of detailed design and the ISO26262 standard addresses the Requirements-based-Testing (RBT) for all ASIL levels.
- In the case of white box requirements, that deal with internal functionality and design, the model can serve as a suitable replacement.
- However, for the black box requirements that describe the behavior of interfaces, which serve as references. for model development, external requirements are necessary.
Conclusion
Employing such systematic and efficient approaches, helps the developers and testers maintain harmony in the V-Cycle. These practices allow MBD engineers to develop large, complex embedded systems with higher reliability, shorter development time, efficient testing and development, and improved maintainability over time.
With increasing complexity, we need better handling of Model-based development methods and focus on these points in mind,
- Leveraging existing models or software.
- Automated pipeline to migrate or test complex models.
- Well pre-defined requirements.
- Reusability and scalability of models.
By taking advantage of the power of models and best practices, it is possible to not only enhance the efficiency and quality of the development process but also position organizations at the forefront of innovations.
