Streamline Automotive SPICE Compliance Using Model-Based Design - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 20:02
Loaded: 0.82%
Stream Type LIVE
Remaining Time 20:02
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 20:02

    Streamline Automotive SPICE Compliance Using Model-Based Design

    See how model-based systems engineering and Model-Based Design can be used in a streamlined way to support your ASPICE compliance efforts when it comes to system and software engineering processes. 

    Published: 7 Aug 2023

    Thank you, Esther. Hello, everyone, and welcome from our side to this talk. My colleague, Marc, and myself want to talk to you today about how to streamline Automotive SPICE compliance using model-based design. But before we start, let's start with a show of hands. Do you or your organization need to comply with ASPICE? Please raise your hand. OK, no surprise. You are attending this talk on Automotive SPICE.

    So we would like to tell you today not everything about model-based design and Automotive SPICE. But we want to show you some highlights of why organizations in the automotive industry choose model-based design and model-based systems engineering to develop products to the highest quality.

    And we picked some samples of the reasons why people tell us why they pick model-based design. First of all, MBD or MBSE let them develop their products in a fast way and in a very efficient way. And that's at the system and at the software level.

    It allows organizations to early test designs and their realization as early as they become available, even before the availability of hardware sometimes. And it allows them to efficiently and effectively go through their iterations. As a result, those organizations develop products to the highest quality. And they comply with Automotive SPICE requirements.

    So Automotive SPICE is a de facto standard in the automotive industry, as you have seen. Almost everybody is speaking the same language. And the standard has a reference model that defines processes that organizations need to fulfill or to comply with. Every process has an ID, a name, a purpose, outcome, and a best practice, and output work products.

    Maybe we don't have time to tell you everything, as I said, but we highlighted or-- some functionalities from those processes from SYS.2, SYS.3, SWE.2, and SWE.3. You can think of those blocks framed in black as our agenda for today. Marc and myself, we will be alternating. Marc will be doing the nice part. I will be telling you the compliance part, how you map those to Automotive SPICE.

    So let's get started with SYS.2. SYS.2 is about system requirements analysis. You start with, let's say, an initial set of requirements at the system level. Probably, those come from stakeholder requirements, from standards, from regulations. You can import those requirements from external tools into model-based design with the Requirements Toolbox.

    You can also specify and author those requirements in the Requirements Toolbox itself. So you can see here how you can organize them in a hierarchical way. So you can group related requirements together with some containers. You can do the usual specification by specifying user-- your custom IDs, the summary of requirements. You give a rationale. You describe-- fully describe those requirements.

    You can describe that in the Requirements Toolbox, or you can even open a Word document to use the rich environment for that kind of specification. You can extend this type of specification with your custom attributes. You can give, for example, an [INAUDIBLE] level for every requirement you have. You can add verification criteria to those requirements. So in addition to those built-in attributes for requirements, you can add whatever you need for your project, for your organization, and to comply with Automotive SPICE.

    All right, you specified your structure requirements. Next is to analyze those requirements. And model-based design has many, many features and capabilities to do that. But Marc picked one interesting use case from that. And he is going to tell us more about that. Marc.

    Thanks, Mohammad. So this is an example of the-- this is an example on how to refine a set of logically and closely related requirements for a DC charging cord of an electric vehicle. We're using the Requirements Table from the Requirements Toolbox to specify the system requirements.

    In this requirements table, every row defines one requirement. We have several columns. The first one would be the Summary field that contains just some textual description. It's followed by the Precondition, which is a multicolumn logical expression then-- that once it's true, meaning that the requirement becomes active. And if the precondition is fulfilled for an instant or for an optional duration of time, then the postcondition, the final column on the right-hand side, has to be true as well. Otherwise, the requirement is violated.

    For the whole table, you can either use MATLAB expressions. Or if you have columns dedicated to certain variables, you can also just use interval expressions to have a nice overview over the different conditions that are coming together. The nice thing is that you can also analyze the table for consistency and completeness with the help of the Simulink Design Verifier, in which case, you're getting a report and some highlightings on the table about things that are not consistent or not complete yet, meaning requirements are missing.

    For this analysis, you can also specify assumptions to specify global constraints that would be considered as well for this type of analysis. So you see that these features, and also others we have in model-based design, help you to specify and refine your system requirements, including the required system interfaces of the components.

    So after we have analyzed and refined our requirements and refined especially the stakeholder requirements, the next step would be to check the traceability of the system requirements with respect to consistency and completeness. And for this, we have the possibility to automatically generate traceability diagrams that you can use, for example, to check the refinement on all the different hierarchy levels. And you also can use traceability matrices to identify, review, modify, correct any linking information between the different requirements.

    Both features are not limited just to requirements. But you can use it for every artifact that links to requirements, such as parameters and data dictionaries, design model elements, test cases, and also interfaces, for example.

    All right, so at the end of this process, you will be able to automatically generate all those artifacts or output work products that you can use as indicators for compliance. For example, you can automatically generate your system requirements in different formats-- the interfaces, traceability, analysis reports for all your requirements, and as well, you can document your verification criteria.

    Next step is to start SYS.3, which is the system architectural design. The purpose here is to start from those system requirements that guide your design, have different alternatives, and evaluate them against some defined criteria. So again, you can have the linkage, as Marc showed us, between the requirements and the design. But let's see how you can perform architectural designs in model-based design. Again, Marc, it's your stage.

    Thanks, Mohammad. Let's see in this example how System Composer can support you with these activities. So this is an example model of a battery management system connected through required interfaces with its operating environment. In this model-- or in this system, actually-- we have several architecture layers, like one for a functional, logical, and physical layer, each represented by different models that you can easily navigate in between by using so-called allocations.

    So here, we're activating allocations. And then on every component on the right top corner, you see the Allocation Links icon that you can use to see a quick list of what other elements from other layers are allocated to this component. And you can use it to easily navigate forth and back between the different architecture layers, actually.

    For a more holistic view, you can also use the Allocations Editor to see a matrix, where you can identify, modify, review of the different allocation links of components and ports. And you can even use some optional filtering mechanism to focus on specific design aspects.

    For every architectural model, you also may want to use the requirements perspective to see which elements of your design have already been linked to requirements. So once these have been linked, you see that there is always this nice icon that you can choose to see the list of linked requirements. And these hyperlinks you can use to quickly navigate to those requirements. In that case, they would show also up on the right-hand side in the Property Inspector, where you see all the details of the different requirements. Linking such requirements is easily done by dragging and dropping them onto the elements of your architecture.

    For every architectural model, you also need to specify the interfaces, either manually or what is shown here is that you also have the capability to import the pin-out and interfaces of a component of its supplier's specification sheet, for example.

    So once we have specified and refined all the different architectural layers, we also may want to analyze them. What does it mean? Analyzing with respect to what? So you have the possibility to specify, in properties, different values for each of the different components or other design elements.

    For this feature, you first need to define what type of stereotypes you want to have and what properties you need for maintaining such data. Did I start the video? No. Now it's starting.

    So you see here, first on the right-hand side, how to use the property fields. And next, we are showing here how to use the Profile Editor to define those stereotypes and properties that you want to use later on to fill in the data for each of the elements. It's also optionally using an inheritance mechanism so that you have a full hierarchy of stereotypes with properties.

    Once you're specifying all those key values for your different elements of your design-- let's say, for example, the costs of a certain component-- you can run an overall analysis-- that's running here right now-- to calculate the total cost of the overall architectural solution, for comparison purpose, for example. So you see here the different columns, especially on the right-hand side-- total cost currently zero because it hasn't been analyzed yet.

    And now, with pushing the button on the Analyze button, you see that the numbers got filled in with different numbers. And you can use this table even to play around with the numbers to do some what-if studies, to see how this affects the overall cost numbers. This is just an example. You can use the same analysis for any type of value that you are interested in.

    After analysis, as we have seen, you might want to trace and check consistency, completeness of your mapping between requirements and architecture models. You have seen this before. But as ASPICE cannot iterate it more, we also we will iterate it as ASPICE. So traceability is very important in this context.

    So you can use the Requirements Toolbox to have that mapping between the requirements and your architecture models. And System Composer itself, if you have different models for functional, logical, physical, and so on and so forth, you can maintain that traceability and ensure the consistency and completeness as well.

    So with that, you conclude SYS.3. And with those output work products as, again, indicator for compliance, you can generate all documents for system architecture interfaces and traceability. Those are just an example.

    Now, actually, before I move to SWE.2, now, at the end of SYS.3, you would be allocating some elements to software, to hardware, and to other disciplines. And that would trigger those phases of development or those activities.

    When they are done and finished, they converge, and then you start your integration at the system level. So we promised you to focus on the left side of the V. So we will jump into SWE.2 of the software architectural design. And you will see here many functionalities similar to the system level, like System Composer allows you to perform those designs of-- at the software level as well.

    Yeah, here is an example of software architecture. You define the components, their ports, and the connection between the software components. That gives you an idea about the static view of the architecture. And when it comes to ports, you might want to define interfaces or types for them. And as you can see here, there is the Interface Editor that streamlines this activity for you, which you can use with the help of data dictionary to have those data types kind of shareable between different models.

    So next is to describe not only the static aspect of the architecture but the dynamic aspect. And for that, Marc, will show us some cool stuff?

    Thanks, Mohammad. So in order to describe the dynamic behavior, we need to understand which other software components we are talking with, from a certain software components perspective. And this is best be done by creating views that shows exactly the direct communication partners with respect to certain aspects that we want to highlight here with this view.

    And once you have such a view, you can also create a sequence diagram. And you can easily start by generating instances of all the different lifelines for each of the communicating components, which is a great starting point, to now specify the interactions between those different software components. This is how it looks like after completing the software interactions between the different components. And you can see this is a nice overview to see exactly the interactions between the different components.

    With that, you can perform some evaluation or simulation of those sequence diagrams. You can even use the same profile stereotypes that we described at the system level to do some evaluations at the software level. You can think of a RAM budget or memory budget, CPU budget. You can do all those evaluations even before you have implementations. And again, you can use automatic report generation to get all those output work products.

    The next step at the architectural level, or architectural design level, you specify your units. And now it's time to detail design those units. So, Marc.

    Yeah, in order to develop the detailed design, you can either use System Composer, Simulink, or Stateflow. In this example, we are creating the Simulink models, skeleton actually, right from such a system component. Alternatively, if we have already a behavior model of a software component, you can just link it to one of the components here on this detailed design view.

    Actually, here, what's happening right now is we are linking a component to a Stateflow model so that the Stateflow model is instantiated for such a software component. And you see here that we have a state machine now to specify the detailed design on this level.

    Also important here is the traceability. And again, here, you see, in this example, the traceability links between the requirements and the different state transitions. Whatever elements you have in Stateflow, you can use the same mechanism, of course, down to the unit level, to establish traceability in both directions. With the help of data dictionaries, you can also specify and document interface properties, such as the data types or the dimensions of your interfaces.

    All right, next is to evaluate those detailed designs. One way is to look at Simulink Check and Model Advisor to check against modeling guidelines. Another one is to look at the Model Maintainability dashboard and see some metrics around cyclomatic complexity or some architectural evaluation metrics.

    Next is to, for sure, to automatically generate code from those detailed design models. And for that you can use Embedded Coder. You can configure it to increase the likelihood of MISRA compliance. And you can configure some parameters towards performance optimizations, memory optimizations.

    And then you can specify that you want to see some reports around the generated code-- for example, the use of global variables, and so on and so forth. You can view the generated code and the model side by side. So you can see full traceability between the design and the generated code. You can also view the requirements in the generated code as comments.

    So with that, you conclude this step in the software-- at the software level. And you can generate all those work products as, again, indicators for compliance. With that, we wanted to conclude our talk. We hope that we gave you some taste of how it feels when you work with model-based design and ASPICE.

    And I'm sure many of you combined the two and have a feeling for it. But we wanted to share with you that model-based design and model-based systems engineering let you develop products for the highest quality. And at the same time, you comply with standards like Automotive SPICE, not only Automotive SPICE but also other standards in the automotive industry, like ISO 26262, as an example.

    And those are just some examples of the benefits and advantages that you get when you use model-based design for that. We just gave you some samples of that support. But the IEC Certification Kit has more detailed mapping document that shows how our use cases map to the best practices of Automotive SPICE. And with that, I thank you for your attention and for being here today with us. Thank you.

    [APPLAUSE]