{"id":4195,"date":"2020-05-27T09:03:53","date_gmt":"2020-05-27T07:03:53","guid":{"rendered":"https:\/\/zen-cori.138-201-132-86.plesk.page\/?p=4195"},"modified":"2022-09-19T11:45:51","modified_gmt":"2022-09-19T09:45:51","slug":"component-based-architecture-in-simulink-for-efficient-unit-and-integration-test","status":"publish","type":"post","link":"https:\/\/www.btc-embedded.com\/zh-hans\/component-based-architecture-in-simulink-for-efficient-unit-and-integration-test\/","title":{"rendered":"Modular Model-based Software Architecture for Efficient Unit and Integration Test"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Model-based design (MBD) is well established in automotive\u00a0to develop embedded software\u00a0<\/span>but with the growing size and complexity of software, handling big sized model is often a challenge. MBD enables to easily craft a software application and from one step to another refine it, test it and generate the production code. However, it’s risky to start modeling without a well-defined software architecture. Because it\u2019s impossible to develop an automotive software as one single function, defining a software architecture helps to break down the complexity and improves the development and testing activities. ISO 26262 addresses software modularity with the principle of \u201cHierarchical structure of software components\u201d and highly recommends it for all ASIL levels. In this article, we\u2019ll see how this principle can be applied using a component-based architecture in Simulink. F<\/span>irst of all, let\u2019s start with some definitions.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

What is a software architecture?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Defining the software architecture is an important step to ensure an efficient development of complex software.<\/p>

Note<\/b>: A software application can be modeled for Rapid Prototyping without a detailed software architecture definition but later in the development process, testing a piece of the software in Software-In-the-Loop (SIL) will be impossible if the corresponding function is not present in the production code.<\/i><\/p>

The software architecture describes the elements that constitute the software and their interactions. This includes static aspects such as the hierarchical structure, executable functions, interface variables, datatypes, etc. as well as dynamic aspects such as execution modes\/timing\/order, temporal constraints.<\/p>

In many projects we observe that the notion of software hierarchy is present but the definitions are not standardized. \u00a0We often hear terms like \u201cModule\u201d, \u201cFeature\u201d, \u201cFunction\u201d, \u201cUnit\u201d, \u201cComponent\u201d, \u201cApplication\u201d, etc. but from one project to another, they are used differently. In the\u00a0AUTOSAR standard<\/a>, there are three levels of hierarchy with standardized definitions: Composition, Atomic Software Component and Runnable. The Runnables are the executable software entities and the Atomic Software Component and Composition are encapsulation levels. In\u00a0ISO 26262\u00a0Part 6<\/a>\u00a0we see two terms: Software components and Software unit. The Software unit is considered to be the lower level piece to design the software and a software component gathers one or multiple software units in an encapsulation fashion. Independently from the terms being used, the concept behind a hierarchy of dependencies shall be clearly defined in the organization. Nevertheless, if a project has to comply with a standard, it\u2019s recommended to use the same definition and wording of the standard. In this article, we\u2019ll describe the component-based architecture in Simulink using the terms of the ISO 26262 standard: Software component and Software unit.<\/p>

Ultimately, a dedicated tool shall be used t<\/span>o design the software architecture. For AUTOSAR architecture, it makes sense to use an AUTOSAR authoring tool but in general, professional software architecture tools offer sufficient features and abstraction to design the architecture. For more efficiency in the model-based context, it\u2019s recommended to use a tool which easily integrates with the model-based environment.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

What\u2019s a software unit?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

According to ISO 26262, a software unit is an atomic level of a software component that can be subject to standalone testing. One or more software units constitute a software component.<\/p>

Characteristics of a software unit<\/strong><\/p>