Hi, my name is Sascha Ridder. And in today's Innovation Coffee Break,
I would like to give you six basic tips on how to start modeling properly in AUTOSAR
and generate efficient code for your automotive functions. In my view, the most important thing
is to maintain an overview of the architectural specifications
throughout the entire development process. So let's directly move to the first tip. Well, it might sound very straightforward
and basically is a mandatory step when working with TargetLi
nk and AUTOSAR. So, however, tip one: Use the supplied ARXML
and store it centrally. The ARXML supplied by an architect
contains all the information on the basic structure of the software. This information should be consistently
and centrally stored and managed for modeling and subsequent code generation. To do so, import the ARXML to the TargetLink Data Dictionary to maintain consistency
across the architecture and software information. Using the TargetLink Data Dictionary in general,
and speci
fically in the AUTOSAR use case, due to importing all the information
on the AUTOSAR architecture, guarantees that the information
required for modeling is stored centrally for the development process with TargetLink. But what to do after that? How can I now transfer my architecture
from the TargetLink Data Dictionary to the TargetLink model without errors? That brings me to tip two: Use a frame model generator
to generate the model. This keeps the model and the software architecture information
in sync. Once all the important information on AUTOSAR
has been stored in the TargetLink Data Dictionary,
you can generate a frame model from TargetLink. Here, TargetLink generates a model
that contains all the AUTOSAR information required for modeling. And finally, you can now start modeling
in TargetLink as usual. But let's stay with the consistency
of the model and the architecture. Here I'd like to talk about
how you can ensure that consistency is maintained even when the
architecture is up
dated after modeling or code generation
and how you can check this. There are different approaches,
which I would like to point out in tip three: Keep calm and use comparison tools
and update mechanisms. Let's imagine the software architect
changes the architecture of your software component
and delivers to you a new, enhanced updated ARXML file. In a first stage, you have the possibility
to directly compare the two versions of the ARXML files with
dSPACE AUTOSAR Compare. This product gives you
a quick overview
of the changes in the two ARXML file versions. It also allows you to integrate
your own changes using the match functionality
by dSPACE AUTOSAR Compare. This approach gives you the opportunity
to easily and quite early see the differences
between the two versions and resolve potential conflicts
and merge changes accordingly. From a TargetLink-heavy point of view,
we also need consistency both in the TargetLink Data Dictionary
and in the model. Again, the TargetLink Data Dictiona
ry
import mechanism is also useful in this update scenario. So when importing an ARXML,
you have multiple options to do so. With an ARXML import
to the TargetLink Data Dictionary, in an existing TargetLink Data Dictionary workspace, you can either directly update
existing TargetLink Data Dictionary properties or, much safer,
you can first import the updated ARXML into another, a new,
TargetLink Data Dictionary workspace. Here you can then trigger
a comparison of the two TargetLink Data Dictionar
y workspaces
and hence, of course, the two ARXMLs. Once the code has been generated,
you should again check the consistency between the ARXML created by TargetLink and the ARXML specified by the architecture. At that point, you can compare the result with dSPACE AUTOSAR Compare again
and do some merging if necessary. So we come to tip four: Test your AUTOSAR models and software
as early as possible. Targetlink with its MIL, SIL, PIL test functions has offered good and simple ways
of testing soft
ware components in the development environment
for decades, both in non-AUTOSAR and AUTOSAR use cases. So let's start with SIL and PIL. Here, of course, testing is obviously difficult because clearly an RTE
or adaptive middleware is needed here because the software,
the generated software, has implemented appropriate calls
for the interaction with a classic RTE or adaptive middleware. TargetLink provides functionality
for this specific test use case. So while generating code for classic AUTOSAR,
TargetLink also generates a non-production RTE. We call this the "stub RTE" for SIL tests in TargetLink. It mimics communication via the RTE,
although it does not even exist yet on production level. A similar approach applies
to the adaptive AUTOSAR use case, although it is still clearly more complicated
than for classic AUTOSAR. However, once again,
even for adaptive AUTOSAR, TargetLink provides assistance
to test early in the development environment. TargetLink encapsulates the middleware cod
e
in the software via compiler macros in such a way that in SIL mode
on your local machine, the communication is mapped directly
via internal communication within the adaptive AUTOSAR function. This abstraction layer allows you to test your software quickly, easily, and cost-effectively in both AUTOSAR use cases. That brings me to tip five: Use signal injection for status signals in MIL, SIL, PIL, such as return values from either RTE API functions
or calls to the adaptive AUTOSAR middleware. Ev
en if the RTE,
the Adaptive AUTOSAR middleware, or some functions,
such as the mentioned server replying to a call
is not yet available at the time of the first software test, it is still possible to simulate that
with a signal injection with TargetLink. Using the sender-receiver ComSpec blocks in TargetLink models, it is possible to simulate the RTE status signal invalidations, transformer error logic, or adaptive AUTOSAR error handling, among other things. This gives you the possibility
to tes
t your own component very early in the development stage
on your local machine. But even on a more complex level,
you can still test quite a bit in TargetLink if you use the
available onboard resources. So finally,
let me introduce you to tip six:. Simply do the first overall software test
in your development environment. With TargetLink 5.2,
we introduced the first support of importing and generating AUTOSAR software component compositions
into TargetLink. And that means with a push of a button
,
you can import AUTOSAR software component compositions
into the TargetLink Data Dictionary, generate a frame model,
and use the update mechanism to ease your own efforts
to simulate the software functionality in a more complex interaction
with other software components. This in return gives you the chance
to test the system in terms of a first rudimentary test
in Simulink and TargetLink. But as I mentioned before,
very complex tests where the production RTE is needed
or where you want to test
the software with an environment model, should be done in virtual test solutions, such as the dSPACE SIL testing solution,
or in hardware tests. Now before I would like to end here,
here is a final piece of advice. There are a lot of additional things
which can be done with TargetLink in terms of AUTOSAR. For years, there's been an additional,
free-of-charge tooling that provides some blocks, helper tools,
and comfort functionality: the TargetLink AUTOSAR utilities. For example, there are specia
l block libraries that consist of blocks for NVRAM,
which allows for generating required RTE calls, for the NVRAM Manager, E2E protection, or blocks that provide RTE calls,
such as Rte_Enter, Rte_Exit, Rte_Trigger. Just to name a few. Further, the utilities provide some comfort functions to create an operation core subsystem
automatically from the TargetLink Data Dictionary, a dialog to add properties of RTE events
or just to simplify settings for some ARXML import and export options
in the Targ
etLink Data Dictionary. These utilities are available for download on our web page. They also include some additional demo models
that show you how to handle, e.g., NVRAM, or embed incrementally generated,
non-AUTOSAR model fragments into AUTOSAR software components. You will find the link to the download page in the show notes. This is a lot of information,
and I did not go into much technical depth. I hope, however, that after this little excursion into the AUTOSAR modeling world, nobody is af
raid of AUTOSAR anymore. I hope that it has become clear
that by using MBD in the AUTOSAR use case, you can also take advantage of all the benefits of the model-based development world. And at this point, I would like to refer to our tutorial videos, our excellent documentation section,
especially the AUTOSAR Modeling Guide, and the demo models that are included in our documentation. And of course, my colleagues
from TargetLink support and engineering. On this note, thanks for listening
and I h
ope you learned something new about AUTOSAR and TargetLink. And if I sparked your interest
in AUTOSAR software development with TargetLink, just write me to start a deeper conversation about it.
Comments