System and Software Development and Safety Analysis for Digital Product Development - MATLAB
Video Player is loading.
Current Time 0:00
Duration 22:13
Loaded: 0.74%
Stream Type LIVE
Remaining Time 22:13
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 22:13

    System and Software Development and Safety Analysis for Digital Product Development

    Sharath SL, Bosch Global Software Technologies

    The automotive industry has seen major changes in the span of just over a century. We are experiencing an exciting digital transformation. The need for new product development methodology, processes, tools, and architecture is amplified by trends such as electromobility, automated driving, and modern mobility services. For such applications, software is essential. Future vehicles will be distinguished by software and digital features that can be updated on an ongoing basis rather than classic characteristics such as engine displacement.

    Our priority is to adopt well-defined processes, methods, and tools for digital product development by bringing in agility and predictability to key challenges:

    1. Defining the digital blueprint for the systems upfront during product development
    2. Adopting an MBSE approach in a holistic way
    3. Synchronizing system architecture and software architecture
    4. Creating traceability across the life cycle
    5. Adhering to various standards like APSICE and ISO 26262
    6. Performing model-based safety analysis
    7. Improving code quality
    8. Reducing design effort and communication overhead<
      1. Adopting systems engineering methodology to provide a structured approach to solving complex engineering challenges
      2. Using tools from MathWorks like System Composer™ to define digital blueprints for our engineering systems
      3. Verifying dynamic behavior of our systems using MATLAB® and Simulink® during early stages of our development life cycle via modeling and simulation techniques
      4. Generating production code from models to improve efficiency and quality
      5. Achieving traceability easily between system and other multidisciplinary elements (software, hardware, and mechanical), eliminating manual traceability and improving new features like suspect linking
      6. Reducing overall development time by 30–40%.

    Published: 30 May 2022

    [MUSIC PLAYING]

    Good morning, everyone. Good afternoon, good morning, good evening, everyone. So great to be a part of MATLAB EXPO 2022. So thanks a lot for providing this opportunity to talk on the topic called System and Software Development Using MATLAB Products for Digital Product Development.

    To start with, so what we have today right now is if you look at the innovations in the last 100 years in automotive industry or any other domains, so if you look at the innovation just purely in the automotive space, there has been a lot. We can see, just by looking at the picture what we are seeing right now on the screen.

    The way the car used to look, the car is look 100 years back and the vehicle is looking today, there's been huge transformation. And we are in a typical phase, we're in the most important phase wherein we are seeing a lot of transformation in the automotive industry, be it in terms of connected, or be it in terms of automated, or electrified, or at the same time, personalized.

    So every industry, similar to automotive industry, undergoing huge transformation. And innovation is a key driver. So around this innovation, what we can see at the same time is we are living in a world called VUCA world, VUCA stands for Volatility, Uncertainty, Complexity, and Ambiguity. If you look at this picture, this is from the recent Australian Open. And in the final match.

    So if you look at this win predictor here, if you just focus on the center of the screen, the win predicted before match, it was around 64% for Daniil and 36% for Nadal. But after the third set, within the beginning of the third set, if you look at the wind prediction, the prediction says that Nadal has got 4% of chances of winning this final.

    But if-- and if you look at today, the end result, it's Nadal who won the Australian Open this year. So overall, what we can convey here is be it in sport or be it in engineering aspects, it's hard. When we're all dealing with things, it's hard to predict, just looking at this example at sport, it's hard to predict the future, even if we have good amount of data sets or data points available, it's hard to predict.

    So connecting back to the engineering system, it's the same thing what we are also seeing here in terms of engineering systems. So we are all living in a VUCA world, which is highly volatile, uncertainty, and we are all dealing with complex systems. As we saw in the first slide, the engineering systems have gotten a tremendous transformation. So as I mentioned earlier, today is an era when it's all about automated, connected, and electrified.

    So this transformation is adding a huge amount of complexity on the engineering system, what we are developing, and that engineering systems. So to make such engineering system a world class engineering system or a digital product development, focusing on the transformation, we need to have a holistic approach towards development process.

    At the same time, we need to have a well-defined process methods and tools. So purely going by what we are seeing how the future mobility looks like, it will be 10 years from now, the amount of electric cars which will be running on the road to exponentially increase. At the same time, we'll also be seeing automated.

    So we all know that steering itself is becoming a commodity. So we'll be seeing more and more innovation, or more and more efforts put towards automated. At the same time, you'll also be seeing a lot of use cases in and around connectivity. So the future mobility, if you just take these three aspects, it's definitely going to put a lot of stress on innovation.

    At the same time, the subsystems are getting complexity. So how are we going to achieve such complex? How are we going to achieve such complex systems, and what's driving us? So today, at the same time, one of the key aspects, today, basically what is driving us, the innovation is about the software. Software is playing a key role.

    If you look at the slide on the left hand side, it clearly says the amount of-- the number of lines of code, number of lines of code getting into the car. It's close, I think today, we have got more than 100 million lines of code getting into the car, with more and more innovations going in the space of connected, electrified, and automated, it's going to exponentially increasing.

    So just by looking at this slide, we can assume one thing, or we can come to a conclusion that software is going to play a key role. And systems and software will have to work together to address the complexity, at the same time, keeping in terms of-- keeping in terms of all the various aspects coming out in terms of standards like ASPICE or regular safety standards like ISO 26262.

    So there are a lot of-- a lot of aspects which we need to address. But what lies at the center is the software and systems. So software and systems, we need to have a holistic approach to address these two areas.

    Now, connecting what we saw so far is about how complex our systems become-- systems are becoming, since we just have to transform ourselves. At the same time, we also saw an example of the world we are living in the terms of VUCA. And we can-- today, we connect-- we're able to connect [INAUDIBLE] also to the engineering systems.

    Now, looking at the engineering challenges, what we have, or what we are facing, or what we are going to solve in our day to day activities to make our systems more complex, or to make our systems more smart, smarter. So one of the key challenges what we saw, the first key challenge is about-- it's about collaboration is one of the key thing.

    So today, probably, one or two decades back, when we had a lot of time to-- when we had a lot of time to bring in to develop systems. So we always had-- and we always felt that a better collaboration will address complexity in a much, much better way. And today, if you look at the number of interfaces or the elements, it's also increasing.

    And one of the key challenges what we are addressing to define a well-defined complex system such as complexity, what we also need is to have a holistic approach for our product development. So one way of achieving that is about adopting or inculcating practices like model-based systems engineering.

    So probably I know the many organizations we have, if you go back one or two decades or three decades back, more or less, we used to-- we have got practice in adopting document centric way of doing things. We did used to generate tons of document. But today, since the time is also shrinking, the time to deliver the product starting from ideation till release, it's also shrinking.

    So we need to-- one of the key methodology we can adopt is model-based systems engineering. At the same time, what we also need today is synchronization between systems engineering and the software engineering aspects. And software is going to drive a lot of-- software is going to be the center of the development processes.

    And the other thing is about-- the other challenge, the fourth challenge, what we are seeing is about the common software and system centric understanding is very much required to address various challenges, which are defined by regulators. It can come from a regulatory aspects. Or it can come from satisfying some of the standards, like ASPICE and other things.

    So shorter time to market is the need without compromising on the safety and other aspects. So that's also another key challenge which we're all seeing. And as I mentioned earlier, one of the things-- one the key challenges is also to collaborate. So when you talk about systems, system is all about software, hardware, and mechanical. So how easy, what are the most efficient way where we can collaborate all these things in order to bring in agility, predictability, and high quality?

    So when teams collaborate in a much better-- much, much better ways, we can see that collaboration will bring in agility. And collaboration will also improve the quality of the products that what we deliver at the end of the day. And also collaboration will also help us to bring in the agility, also will be able to help us in predictability, bringing the predictability.

    So to address all these challenges, what we experience is adopting one such methodology, MBSE will solve a few of the challenges what we saw in the transformation from document centric to model centric world. So to adopt MBSE, it's also about mindset change. So since we are doing things in a certain way of doing things, for example, here in terms of document, we have document centric way of doing things, all of a sudden, if you want to transform ourselves from document centric to model centric way of doing things, it requires a lot things from mindset change, and also that's one thing.

    And the second aspect is about we need to have well-defined processes, methods, and tools within our organization to adopt such practices or methodologies. So what we have done here is we have adopted tools from MathWorks which have-- which have enabled us to enable us to do such-- undergo such transformation in a holistic way.

    So one of the other approaches, what we have seen here is about approach to drive this transformation. So, for example, there are two separate approaches what we have observed. One is moving towards a model-based systems engineering. And that other approach is about model centric development.

    The first approach, what we are seeing here on the left hand side is so we have use cases. Let's say we have use cases which will be derived from the marketing departments. And from use cases, we derive the system requirements. And from system requirements, we will derive the functional architecture. The functional architecture is basically the what part of it, what are the system functions.

    Then from the functional architecture, we derive the technical architecture. So this, more or less, these blocks will help us to move from what-- will help us to move towards model-based systems engineering. This is one aspect of it. And the next aspect is how we can leverage model-based systems engineering to solve larger challenges or larger complexity. So what we have observed with our research and also with our experience is that model-based-- if you have model at the center of the development process, it will be the model we can address a lot of such challenges and also address complexity.

    So what we are trying to achieve today, and we have achieved some sign of-- some steps here is we all wanted, since the model is alignment information. So the model will be at the center of the development process. [INAUDIBLE] when you talk about models, there will be-- we will have engineering models starting from the system level and also the software level.

    So system model is the-- system model is a blueprint of our system. It will be at the center of the development process, revolving around it, all the other aspects of engineering comes-- it can be a CAD models, or the control models, developed with the help of tools like MATLAB, Simulink, or Simscape, any of the tools.

    And also revolving around it is the engineering lifecycle management things. For example, if you talk about requirements, engineering requirements, engineering is all about requirement development. And we also need to have a well-defined tools for managing our requirements. So what we can achieve if you have-- what we have achieved is keeping this model at the center of the development process, we have achieved various requirements from ASPICE.

    One of the requirements of the requirements from ASPICE is about traceability. So ASPICE-- we need to achieve traceability from requirements till test. So since the model is at the center of the development process, it was easy for us to achieve traceability from requirements to the system models, from different system models to the control models, and then from the control models also to the test cases, which is being part of test management tools.

    So what we can achieve here is what this picture, what we are seeing here is it's about bringing in various aspects of application lifecycle management, product lifecycle management together, and also all the information or the language of information is at the center of the development process.

    Moving on to the tools which we have used in this journey, so if you look at the typical life-- typical V model. So here, we talk about requirements, engineering from stakeholder requirements, we derive our system requirements. And then from the system requirements, we will define the system architecture, system architecture comprises of functional architecture and the technical architecture.

    And functional architecture is the what part of it. And the technical architecture is the how part of it. How are you going to allocate? How are you going to implement those functionalities? And then if you go one level down, so then the system architecture or system requirements will be broken down into software, hardware, and mechanical requirements.

    And then every V will have, for example, software requirements. From software requirements, we are going to derive software architecture. And then corresponding testing will be done. So if you look at the tools which we have used, focusing on-- by addressing the various aspects of system and software.

    So we have used Simulink Requirements at the top to bring in traceability. And we have used System Composer, is one of the tools from MathWorks which has enabled us to define the blueprint of digital systems. At the same time, it has also enabled us to bring in aspects like traceability.

    So what I think-- in a typical scenario, tools play a key role in any development process. If you look at one of the challenges for collaboration is within the engineering teams, one of the challenges which we usually face to bring in a better collaboration between engineering teams is all about teams will have different tools for their own development processes.

    And if you want to achieve things like traceability, then that's one of the challenge. Because the data will be learned in different systems. Data will not be centralized. So one of the key-- those are some of the challenges which we have solved by adopting tools from MathWorks. So System Composer is one.

    And in the area of software-- in the area of software engineering or in the area-- in the area of developing control models, we use tools varying from MATLAB, Simulink for modeling, Stateflow for event-based modeling, Simscape for physical modeling, and then one-- one of our requirement is also to generate the code from the Simulink model to link our Stateflow models.

    And then use tools like Static Code Analysis, tools like Polyspace Code Prover and Bug Finder to help us do static code analysis, focusing on improving the quality aspect of it. OK, so far, I think what we have seen is about what are the technical aspects which we have inculcated to undergo such transformation using tools from MathWorks, like System Composer and other tools.

    And also we touched upon how-- at a very high level, we touched upon how did we achieve that. So if you look at the journey about how did we go about bringing in or adopting a tool from MathWorks product family to address some of the aspects of MBSE and also doing-- I know some of the aspects of software engineering, be it in terms of control, in terms of developing control models.

    So what we did is, so since it is also a need for us to adopt in terms of using System Composer, since we also wanted to try out. So what we did is we initially we had a roadmap and blueprinting phase. What is we want to achieve with the key challenges, like adopting model-based systems engineering, one challenges which we wanted to adopt also.

    At the same time, we also wanted to keep in mind about the various requirements from ASPICE, and safety, and all, like traceability and others. So then what we did is about we took a small pilot projects and tried to use this-- tried to use data to define the process methods and tools for our pilot projects.

    After the learnings from the project prior-- learnings from pilot projects, basically, we got the feedback for our fine tuning. And then once we are-- once we are successful in the pilot projects, then we started implementing for a large number of projects, which are more or less our critical projects.

    So based on the learnings, it's a continuous learning and continuous feedback will be with it. And then it's about the rollout and trainings at an organization level. And then the maintenance and enhancement. So what I can definitely say here is that realization of addressing key things like complexity and also the various requirements from standards, we have adopted model based systems engineering as one approach.

    And tools from-- tools from MathWorks have enabled us to undergo that journey in a smoother fashion. Looking at the benefits of what we have achieved so far. So one way, what we have observed is MBSE can definitely address the complexity and can definitely bring in aspects like agility in our product development process.

    And since simulations are-- since we have adopted simulations and modeling and simulations at the very early stages, so it has helped us to bring structured approach for the development process and also address complexity at the very early stages, since simulation is one of the-- key thing about doing simulation is also to verify our designs in early stages. So what happened is by doing this, we were able to define a blueprint for our systems up front during the product development process.

    And the same blueprint can also be shared across the downstream. For example, the system architecture can be shared with the software architects, who will be consuming that for better design or a better view of the products. What happens if we don't have the system architecture up front?

    So then we'll [INAUDIBLE] a lot of assumptions when we are understanding, because better understanding of the systems is very much necessary today, since we will have less time to do the rework later. And also since we are all dealing with the complex systems. And tools from MathWorks and System Composer that have helped us, as I mentioned earlier, to define the blueprint for our systems engineering systems, be it in terms of defining the functional architecture or non-technical architecture, or bringing the traceability requirements, system requirements to the functional and technical architecture down the line.

    And also the most important aspect is about verifying the behavior. So we are able to successfully bring in-- with the help of MathWorks and its various toolboxes-- we're able to successfully do the dynamic-- do the behavior-- modify the behavior, dynamic behavior, and also fine-tune our systems based on the data that-- or the feedback, whatever they used to get, before V1, getting into this testing of our functionalities at the product level.

    So basically, what we have experienced it, ideally, we can convert a PC or a laptop into a laboratory device with help of these tools. And the other benefit what we have leveraged is about letting production code from models, which have improved a lot of quality, because there will be no human intervention there.

    Since the production code-- and also, it takes less time to even implement the functionalities when you compared to handwritten code. So other aspect benefits what we have achieved is it was easy for us to satisfy a lot of aspects from ASPICE and other standards. So traceability is one.

    It was very hard for the two of us to achieve traceability from requirements to architecture, architecture to system architecture to software architecture, and also to the test cases. So with looking at all these aspects, what we observed is the overall system, overall development time itself was reduced by 30% to 40%, which itself was a very great benefit for us. So that's all from my side. Thank you.

    View more related videos