Effective Model-Based Development Strategies for ASPICE and Safety Compliance - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 14:49
Loaded: 1.12%
Stream Type LIVE
Remaining Time 14:49
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 14:49

    Effective Model-Based Development Strategies for ASPICE and Safety Compliance

    Peter Abowd, Kugler Maag Cie
    Steve Tengler, Kugler Maag Cie

    Overcoming the challenges of effective software architecting and detailed designing in hybrid model-based and code-based environments, and doing so in a compliant manner, requires strategic decisions among the project team. These strategies, as well as compliance, are often not well formed or understood by project teams, and the answers are complicated in hybrid environments. This session will demonstrate how model-based development can be compliant in similar fashion to hand code but also have distinct advantages, especially when utilizing key features of Simulink®.

    Published: 30 May 2022

    All right, hi, folks. My name is Peter Abowd. I'm with Kugler Maag Cie North America. Going to talk today about model-based development and automotive SPICE compliance-- thrilling topic, I'm sure, for you all. You're sitting there with bated breath. I can tell. So Kugler Maag does dozens of assessments annually-- in 2021 alone, 250 assessments. Globally and more than half of those included some form of model-based development. Lots of times because we need system and software architectures described, those utilized some form of model creation.

    Some of them also do code generation from those models. This discussion today is going to be focused on just the model-based development for the embedded software. We're not going to address the system level processes of ASPICE. OK? And we're going to look at the challenges that you might encounter with compliance when using model-based development, and dealing with the architecture, detail design, and implementation processes of ASPICE, and try to understand where some of these different pieces of the models fit in and what's detailed design in a unit-- so forth.

    Just heard one definition of a unit, and we won't be far from that, so there'll be some clarity, and maybe that might spark some questions for you guys. So we're not going to teach design in 15 minutes or so-- probably couldn't teach it in 15 years. So hopefully what you'll get out of this is a good start on understanding in a compact way to be compliant.

    And what we're going to be talking about so we're all on the same page-- there is the problem, or the what and the requirements. All these things describe what you want or what the customer wants. And then there's your architecture, which is the solution-- which, in some ways, you could consider is completely arbitrary. It's the decision of the design team to create a solution to the problem.

    Architecture is kind of the first-order description of that solution. All right? And the pieces it describes-- in collaboration, they satisfy the features or the requirements. So a feature's realized through the combination and coordination of those explicitly engineered packages of functionality that we have in our design. And those are then put together in a product or a product within a subsystem. OK? So we're talking about the design, not the requirements.

    And so we get through that confusion, and then there's still more confusion about, well, what is the system? Then we're supposed to be helping the team. When we talk about architecture, we're helping the team understand, what are the pieces and the purposes of the system, and the roles of those pieces? And we use abstractions or views, and MathWorks uses abstractions to talk about the pieces of the solution. So you should all be fairly familiar with that concept.

    But from a business perspective, why is it valuable? Not just for automotive SPICE compliance-- it's important to understand which pieces are more critical than others, and why. Which pieces do we want to reuse? Which pieces are safety-related, and therefore should be less volatile so that we can maintain their quality and so forth? And understanding this about the pieces of our solution is a business benefit-- help reduce redundant engineering costs, because most of you are working at tier ones or OEMs that keep putting out a very similar product year after year after year. It evolves, but its core being stays fairly intact, and so we shouldn't have to redevelop a lot of it. But if we don't understand the pieces and the motivations for why those pieces exist, then we might not preserve them. OK?

    So on the right side here we have a System Composer picture. It could just as easily be the top sheet of Simulink. But this represents the top of a software solution. So if you were to look above this, you'd just see one box that says, hey, this thing. And then the next level down are these pieces. So this is the first level, and lots of times this is what gets presented as, hey, here's our architecture, these pieces.

    At least in the context of Simulink or System Composer, there is some definition of the semantics of this view, but beyond that, very little about why it shows those pieces, and which of these pieces might be ones we're making versus buying, which ones are we reusing? And so the diagram itself is necessary, but not sufficient for an architecture. These tools, the MathWorks tools, do a great job of helping specify interfaces and identify the pieces that are being interfaced to and from, but you have to do-- excuse me-- further work to clarify your motivations.

    And then you have to overlay some of your own semantics to say, well, when will architecture and detailed design begin? And that's something that we'll discuss today as an example of how you can do that with these tools. And then really, understanding, what are the pieces, and why-- why did you choose to make these pieces, and what were your guidelines so far. So those things are necessary part of compliance at level 1 and level 2 for architecture.

    So let's go through solving and addressing some of these points about, what is bad design, where does architecting and detailed design end and pick up, and then what are possible solutions for what's a unit, and why. So sometimes it's easier to talk about what something isn't, as opposed to what it is. So here we're going to give some examples of what isn't good design, because it's bad.

    So the design doesn't make any more sense than the code, well, there you have it. It sounds like a Jeff Foxworthy joke. It must be bad design. If you have pictures, but you don't have any semantic descriptions or rules of those pictures of what the boxes mean, what the lines mean, what the color means, what the type of line means, what the arrow means, and-- it's definitely not good enough to just say, well, it's UML, because that's like saying it's the dictionary. Everything's in there.

    Then you need to have justifications. Why did you choose to make this piece separate from that piece, and so forth? If you have a lot of pieces, but you don't show coordination amongst the pieces, that's not a complete architecture. If you have something you call the architecture, like this diagram, well, here's our architecture picture, and then you got all these pieces that exist as well, but there's no relationship between them in the architecture, you got a bad design or a design problem, a discontinuity for sure.

    Why is this important? Because some of this is related to ASPICE compliance. Some of it is just related to good design practices. It's because design is your chance to prevent failure where it's inexpensive to do so, as opposed to not preventing the failure and then having the defect on the right-hand side of the V, where it can take 10 to 100 times more effort and cost to find and fix the failure. And so you want to improve your designs and improve your ability to evaluate the designs ahead of implementation and integration, because it's faster and less expensive to fix it.

    All right, so let's walk through an example of some Simulink and MathWorks tools solutions, and how to align them with some of the more critical principles of ASPICE. So the upper left-hand corner here-- we have a System Composer review-- which, again, could be a top sheet of Simulink-- with a bunch of boxes and lines on it. In System Composer and Simulink, those boxes and lines have semantic definitions. All right?

    But what isn't defined, as I said earlier, is what do these different boxes mean? This one has a title highway lane follow, but it would be supported with other justification of why we've isolated it and why it has these particular interfaces. But if we take it, on the upper right-hand side, we have its detail of the highway lane follow element, and these are its subelements, if you will. And ASPICE-- it calls all the hierarchy of items in the architecture elements.

    So we'll refer to these as subelements of the highway lane follow. And then we'll take one of those subelements, and in the lower left, we see its model picture. And it's made up of several model references. And here, we're going to say, is the boundary between architecture and detailed design. This is the end of architecture. ASPICE would call these-- refer to these as software components.

    They're no further decomposed at the architecture level, so they represent an atomic piece of the architecture. And so from an ASPICE perspective, these pieces, these components, which are part of this subelement-- they need a detailed design. And in ASPICE, the role of the detailed design is to say, how shall the component, the software component, be realized in units?

    And to do that, we need a detailed design of this component. So now we've just rotated things a bit. The upper left is now the subelement details of its components. We're going to take one of those components-- the EstimateLaneCenter, for example-- and its model reference file is its detailed design. It's really the dynamic behavior description of its detailed design-- dynamically runs from upper left to lower right.

    And the model reference will generate consistent source code, and that source code file that it generates-- that's the unit. Unit has to be, in ASPICE world, programming construct. So it's got to be code. It could be a class. It could be a file. It could be a folder, package. So in this case, it's this C file that's generated from this model reference.

    So we have all the bases covered. We had an architectural description of a couple layers-- three down to this upper right diagram-- of components. Those components-- that's the end of architecture. And we need a detailed design. That's the model reference detail. The unit is the code generated from that model reference. Now we're all set up you.

    You all know the real power of model-based development at this point is that we've got this generated code, and we can now do some interesting harnessing with it. We can first harness the model itself and do a MIL evaluation. MIL is going to evaluate the design, part of SWE.3, to see if the design satisfies the requirements.

    Then we can take the generated code, and either on the host or in a target environment, we can rerun this testing now on the generated code, and that satisfies unit testing-- especially when we back to back compare the results of SIL or PIL to the MIL to confirm that the unit correctly implemented the design-- which, for the most part, shouldn't be a big surprise, but depending on the PIL environment that you run this in, it could be enough of environmental difference that might trigger something in your design.

    So we can perform static analysis on that source code. And now the combination of the unit test results in the static analysis, and the fact that typically you can justify away doing peer reviews on generated code-- you've covered the bulk of SWE.4-- not really getting into the traceability and consistency evaluation parts. Those are a little bit more consistent for model-based as they are for hand code, but here it's what are the pieces of the design in the architecture that's critical.

    So this is a pretty straightforward approach. It doesn't really require many of you who are using these tools to their full strength to change your behavior dramatically. It just requires that you understand how these pieces and aspects of the MathWorks tools align with automotive Spice needs. And then you have to back up to the architecture and recognize that-- excuse me-- the single picture is not really sufficient. It's necessary, but not sufficient. You need to be able to clarify your motivations, your justifications, your rationale. And those are all not just useful for ASPICE compliance, but really necessary for business efficiency and effectiveness.

    OK, so compliance doesn't have to mean massive behavior change. I just outlined a fairly straightforward approach to align what you do with these tools, and how they can match up with automotive SPICE. And this approach has been shown to be helpful for a number of our clients, and it really doesn't impact the way some of you, I'm sure, are already using these tools. It could be a quite natural fit. Now, that was quick, I know, but hopefully informative, and with enough time here for you guys to convey questions.

    View more related videos