Model behaviour: Autosar

When talking with designers, you can sense their uncertainty and, sometimes, their resistance: Autosar could increase their workload and implementation effort, instead of reducing it. The good thing is that many of these doubts are unfounded. While it is true that increased flexibility, in terms of decoupling applications from target hardware within an ECU network, requires some additional thinking, there should not be a tremendous overhead for the function developer. Developing algorithms that make driving safer, or reduce fuel consumption, or even control brand new techniques of actuation is hard enough. Model Based Design with Simulink and Stateflow is widely accepted as making life easier by providing design, simulation and analysis capabilities, with an integrated path to code. But should we allow Autosar to complicate things again? The goal of Model Based Design is to streamline function development, prevent errors and find remaining errors earlier in the process. Both approaches talk about abstraction of the hardware, as well as easier reuse of components, and this is something that The MathWorks had in mind when adding Autosar Simulink. The question is: what level of knowledge of Autosar is needed? Beyond getting the basic idea that Autosar is a layered software architecture, is it really necessary to dive into the 'nuts and bolts' of the Run Time Environment and Basic Software? Does this help engineers to deliver high quality products? Which parts from the Autosar architecture are important to know about from a function development perspective? It turns out that everything below the Run Time Environment is of little interest for functional development. Communication has to happen; hopefully, this is already encapsulated. ECU peripherals have to be addressed via device drivers; hopefully, this has also been encapsulated. What does this mean? Firstly, there is no need to add blocks to a model to make it Autosar compliant. The design engineer leaves the model's structure as it is and simply applies a different configuration set. Simulink's configuration set concept is essential here; implementation details can be changed, but the algorithm stays the same, regardless of whether a root input port is a plain Simulink port, an Autosar receiver or a port to access Autosar basic software directly. It's just a matter of configuration. There is no need to change models and use some kind of Autosar block set. In fact, there is no such block set. Block sets in Simulink encapsulate functionality that is, for example, special for creating advanced signal processing algorithms. All these solutions have in common the fact that they allow behaviour and architectures to be modelled more easily than can be done with basic blocks. Physical modelling, for example, adds the ability to have bidirectional signal connections between building blocks, rather than the directed signal lines in plain Simulink. In contrast, the modelling constructs needed to develop Autosar software components already exist in Simulink and Stateflow; whether as ports, multiple runnables, multirate models, function call subsystems or complex data types. One of the common fallacies about Autosar is the overhead in runtime efficiency and code size. Often, engineers and project managers worry that Autosar compliant code – including Run Time Environment and Basic Software – will be two or three times larger than non compliant code, with a similar increase in execution time. Autosar 2.1 was the first release used seriously to implement and integrate compliant applications. Many OEMs and suppliers have an internal 'Basic Software' library – sometimes referred to as 'Standard Cores'. While not compliant with the Autosar standard, these libraries have been developed to meet the same goal: decoupling applications from hardware targets. Current Autosar projects often are based upon wrapped versions of these libraries that allow the usage and development of Autosar Software Components. Research shows code size and memory requirements tend to be up to 20% more. But clear statements have been made confirming that Autosar is a good way to reduce complexity. Having determined that function developers and their managers need not worry too much, we should look at how the best aspects of Model-Based Design can be accessed when it comes to Autosar. It is important to recognise that not everyone who uses MATLAB and Simulink already does Model-Based Design, so let's highlight some of the best practices. Too often, organisations do a great job of modelling, but then only use the model for one purpose. We have seen customers who use models only for code generation, without ever having pressed the 'simulate' button in Simulink. In order to best leverage the investment made in software, models must be used for at least two different purposes. Besides production code generation, this could be the validation of requirements by simulation or the automatic generation of documentation. So ask yourself 'what do I do with models?' and 'what does my team, my department, my organisation do with models?'. The rule of two should apply to all levels. This results in best practice. If you find a system defect in a downstream product, resist the temptation to fix it there, because you will detach the executable specification from the reality and thus prevent future reuse. Fix defects in the model: your tool chain should enable you to quickly go down the abstraction ladder again by automating the necessary generation steps. If you change something, change it in the model and gain the benefits of analysis, simulation and instant implementation. Modelling allows you to think about system behaviour, rather than having to think about implementation too early. But, often, people model with the desired C code in mind, but they are not modelling – they are programming graphically and thus wasting the power of the model. If you need some piece of code to appear in the final output, do not redraw it; include it via the legacy code integration possibilities. Otherwise, think about behaviour, not code. Smart organisations learn from their mistakes. Wise organisations learn from the mistakes of others. But who collects those mistakes and transforms them into learning opportunities? Tool suppliers, heavily involved in supporting transitions to Model-Based Design, accumulate experience and can use this to reduce the steepness of the learning curve significantly. By taking advantage of this knowledge, organisations can realise the benefits of Model-Based Design sooner than they would have otherwise and the return on investment breakeven point is reached earlier. Autosar is not as frightening as it sometimes seems. While system architects need deeper knowledge about 'Autosar behind the curtain', function development engineers should not be bothered with that level of detail. In the end, engineers have to be able to solve their challenges and tool suppliers need to support them as much as possible.