See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/282953349

A Versatile Approach for an ISO26262 Compliant Hardware-Software Interface

Definition with Model-Based Development

Article  in  SAE Technical Papers · April 2015

DOI: 10.4271/2015-01-0148

CITATIONS READS

3 3,239

4 authors, including:

Georg Macher Eric Armengaud

Graz University of Technology AVL LIST GMBH
106 PUBLICATIONS   787 CITATIONS    135 PUBLICATIONS   975 CITATIONS   

SEE PROFILE SEE PROFILE

Christian Kreiner
Institute of Electrical and Electronics Engineers
214 PUBLICATIONS   1,493 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Embedded Multi-Core systems for Mixed Criticality applications in dynamic and changeable real-time environments View project

DHYAMONT View project

All content following this page was uploaded by Georg Macher on 07 December 2019.

The user has requested enhancement of the downloaded file.

 2015-01-0148

A Versatile Approach for an ISO26262 compliant Hardware-Software Interface

Definition with Model-based Development

Author, co-author (Do NOT enter this information. It will be pulled from participant tab in
MyTechZone)
Affiliation (Do NOT enter this information. It will be pulled from participant tab in MyTechZone)

Abstract Premium cars in 2009 utilized more than 90 electronic control units
(ECU) implementing close to 1 Gigabyte software code. For 2018,
30% of the overall vehicle costs are predicted to stem from vehicle
Increasing demands for safety, security, and certifiability of
electronics [1].
embedded automotive systems require additional development effort
to generate the required evidences that the developed system can be
trusted for the application and environment it is intended for. At the same time, the higher degree of integration and the safety-
criticality of the control application raise new challenges. Evidence of
correctness of the different applications, possibly running on the
Safety standards such as ISO 26262 for road vehicles have been
same computing platform, has to be guaranteed. In parallel, new
established to provide guidance during the development of safety-
computing architectures with services integrated in hardware require
critical systems. The challenge in this context is to provide evidence
new software architectures and safety concepts. On one hand, the
of consistency, correctness, and completeness of system
development of such systems has to face many cost challenges and is
specifications over different work-products. One of these required
required to support the demands of time-to-market (first time right).
work-products is the hardware-software interface (HSI) definition.
On the other hand, increasing demands for safety, security, and
This work-product is especially important since it defines the
certifiability require additional development efforts.
interfaces between different technologies. Model-based development
(MBD) is a promising approach to support the description of the
system under development in a more structured way, thus improving Safety standards such as ISO 26262 [2] for electrical and electronic
resulting consistency. systems for road vehicles have been established to provide guidance
during the development of safety-critical systems. They provide a
well-defined safety lifecycle based on hazard identification and
Therefore, this paper presents a tool approach for an ISO 26262
mitigation, and define a long list of work-products to be generated
aligned hardware-software interface definition. More specifically, the
[3]. An important challenge in this context is to provide evidence of
approach combines the versatility and intuitiveness of spreadsheet
consistency throughout the entire product development cycle among
tools (such as Excel) and the properties of MDB tools (e.g. different
the different work-products.
views, levels of abstraction, central source of information, and
information reuse) bidirectionally. The approach is capable of
defining an ISO 26262 compliant HSI definition and enables One of these required work-products is the hardware-software
automatic derivation of basic software configurations according to interface (HSI) definition. The HSI specifies the hardware and
the HSI definition. This simplifies concurrent development of software interactions in consistency with the technical safety concept
software and hardware across domain and company borders. and must include the hardware components that are controlled by
software and support the software execution. The HSI is specified
during the system design phase and further refined during hardware
Introduction and software development phases [2]. This ISO 26262 statement
highlights the importance and essentiality of this work product.
Automotive OEMs are investing large sums in the development of
(hybrid) electrified vehicles and networked automotive systems (such The HSI document is the last development artifact of the system
as Car2x systems). Future aims concerning autonomous driving and development and the starting point for parallel development of
the currently ongoing replacement of traditional mechanical systems hardware and software. HSI definition requires mutual domain
with modern embedded systems lead to the significantly increasing knowledge of hardware and software and is to be a work product of a
complexity of the embedded control systems. collective workshop of hardware, software, and system experts.
Furthermore, HSI is used to agree on topics relevant to both,
hardware and software development, and acts as the linkage between
different levels of development.

Page 1 of 7
Insufficient definition of the HSI can cause several additional several abstraction layers (such as application software,
iteration cycles and communication issues between development microcontroller abstraction layers, basic functionality drivers). This
teams. approach usually hides hardware details and establishes software
development teams with specific software focus (e.g., basic software
To handle these issues, model-based development supports the developer, application software engineers, and software integrators).
description of the system under development in a more structured
way, enables different views for different stakeholders, different The AUTOSAR architectural approach [7] explicitly forces such an
levels of abstraction, and a central source of information. approach to support hardware independent development of
Nevertheless, seamless model-based solutions have not been application software modules till a very late development phase and
achieved so far, due to problems arising from inadequate tool-chains therefore enables parallel working of application software developers,
(e.g. redundancy, inconsistency and lack of automation). This basic software developers, and hardware developers. The intention of
hampers MBD approaches in tapping their full potential. the AUTOSAR specifications is to support the exchange and reuse of
software, by defining software architectures, interfaces, and exchange
Therefore, this paper presents a tool approach for ISO 26262 aligned formats.
hardware-software interface definition. More specifically, the
approach combines the versatility and intuitiveness of spreadsheet An emerging domain-independent paradigm for interface definition is
tools (such as Excel) and the properties of MDB tools (e.g. different the contract-based design paradigm. Here the contracts specify the
views, levels of abstraction, central source of information, and input assumptions of a component and provide a guaranteed output
information reuse) bidirectionally. behavior [8]. Such an approach can be used for safety contracts of
software components [9], as well as contract-based embedded system
The document is organized as follows: development [10].
The next section describes related works and the state of the art of
hardware-software interface definition. The existing model-based Another emerging paradigm is system of systems (SoS) engineering
systems and safety tool chain on which this work is based is [11]. SoS are integrations of heterogeneous systems delivering
presented in the third section. The fourth section provides a capabilities and services without exact knowledge of the internal
description of the proposed enhancement for HSI definition. Section workings of an involved subsystem. Basically all current SW
five evaluates the presented approach with an automotive use case. architecture in the automotive domain can be seen as such SoS, due
Finally, the last section concludes this work with an overview of what to their distributed development of SW layers. A promising method
has been achieved. for definition of SoS architectures lies in interface specification and a
quasi-contract-based development. Bryans et. al [11] establish a
State-of-the-Art HSI Definition semi-formal notation to model SoS architectures with SysML. Such a
notation of software architectures is also part of our approach, for
more details see [12].
This section briefly describes the current state-of-the-art approaches
for defining hardware-software interfaces. Although the topic is of
Although, these contract-based approaches foster model-based
high importance for the automotive domain, only few recent
development and traceability of development decisions, they are not
publications exist.
simple and easy enough to be used for HSI definition workshops.
Because of this reason and the project specific nature of HSI
In contrast to this, Hardware-Software Interface co-design has a long definitions many hardware-software interface definitions are still
history in development of System-on-Chip (SoC) systems. Already in done within spreadsheet tools or in textual form within a requirement
2005 Jerraya et. al [4] postulated that co-design of HW and SW management tool. Although Chen et. al [13] claim that social and
interfaces will fundamentally improve the SoC design process and text-based communication does not scale for handling future
increase both hardware and software quality of SoC development. advanced embedded automotive systems.

Kecheng and Fei [5] realized a component-based approach to

HW/SW interface design of embedded systems with a platform- Model-Based Development Fundament
specific bridge specification language (BSL). Nevertheless, their
work addresses modeling system models as SystemC and introduces This paragraph gives a short overview of the model-based
another abstraction layer for hardware abstraction. development tool chain in use and the related preliminary work that
provides the base for the proposed approach.
King et. al [6] postulated the problem of defining HW/SW interfaces
in early development steps. First, a detailed interface is difficult to The basic concept behind the MBD framework is to have a consistent
specify without detailed knowledge of software and hardware. information repository as a central source of information [14]. This
Second, this specification prevents later migration of interface concept allows different engineers to do their job in their specific
functionalities and the addition of features. manner, provides traces between different artifact types, and ensures
timeliness of data. Proprietary extensions for the modeling tool
The reason why HSI development was not the main focus in the ensure seamless and consistent transition of information between the
automotive industry originates from the fact that automotive repository and various adequate special-purpose tools (such as
hardware and software development significantly differ in cycle software development tools). A UML profile, tailored to the needs of
times. Furthermore, automotive software is typically separated into automotive safety engineering, is used to define the model of the
system under development.

Page 2 of 7
 further reworking without the need of special tools, see figure 1
Figure 1. Conceptual overview of the HSI definition approach - spreadsheet tool bridge.
 Spreadsheet importer: Importer to integrate HW/SW interfaces
This enables reorganization from a document-centric development defined with a spreadsheet template, see figure 1 - spreadsheet
approach to a seamless model-based development approach. An tool bridge.
approach, Broy et al. [15] claim to be best to manage large  Spreadsheet template: The spreadsheet template defines the
complexity of modern embedded automotive systems. Fabbrini et al. representation structure for the input data and is customizable
[16] also highlight the importance of model-based development for each project.
approaches in their overview of software engineering in the European  SW/SW interface generator: Generator to automatically define
automotive industry. SW/SW interfaces between application software signals and
For a more detailed overview of the model-based development basic software signals, see figure 1 – RTE configuration bridge.
concept in use, see [17].
Application SW Modeling Framework
Hardware-Software Interface Definition
Approach The first contribution is the development of a specific UML modeling
framework enabling software architecture design in AUTOSAR such
The contribution proposed in this work is a tool approach for ISO as representation within the system development tool (Enterprise
26262 aligned hardware-software interface definition. The approach Architect). This EA profile takes advantage of the AUTOSAR virtual
enables a practicable and intuitive way of engineering HSI definitions function bus (VFB) abstraction layer and enables an explicit
in a spreadsheet tool (such as Excel) and transforms them to a definition of AUTOSAR components, component interfaces, and
reusable and version able representation in the MDB tool (such as connections between interfaces. This provides the possibility to
Enterprise Architect). With this approach, the spreadsheet document define the software architecture and ensures proper definition of the
and system model can be bidirectionally aligned via program-specific communication between the architecture artifacts, including interface
APIs, which support tool-independence of the approach. specifications (e.g. upper limits, initial values, formulas). Hence, the
AUTOSAR-aligned representation can be linked to system
More specifically, our contribution consists of the following parts: development artifacts and traces to requirements can be easily
established. These explicit links can be further used for constraints
checking, traceability of development decisions (e.g. for safety case
 Application SW modeling framework: Enhancement of a UML
generation), and reuse.
profile for the definition of AUTOSAR specific artifacts, more
precisely, for the definition of the components interfaces (based
on the virtual function bus). This is required for consistent SW Figure 2 shows an example of a software module (AUTOSAR
system description and modeling of software signals, see figure Composition) and its signal interface definitions. This integrated
1 - modeling framework add-on. definition of system artifacts and software module in one tool
 Basic SW and HW module modeling framework: Enhancement furthermore supports the work of safety engineers by adding values,
of a UML profile to describe basic software (BSW) components visual labels for safety-relevant software modules, and enables the
and HW component interfaces. This is required to ensure automatic generation of interfaces to BSW modules. Furthermore the
consistency of the specification and configuration of BSW model representation enables constraint-checking features and
components and modeling of the hardware component supports signal traces to HSI definition and requirements.
interfaces, see figure 1 - modeling framework add-on.
 HSI definition exporter: MBD-tool extension to export the
resulting HW/SW interface definitions to spreadsheet tools for
Page 3 of 7
 Figure 3. Example of a port pin connector artifact, basic software (BSW)
signal, and the corresponding connector pin settings.

Spreadsheet Importer

The MBD-tool import-extension is the corresponding counterpart to

the HSI exporter. It is also a dll class library using the spreadsheet
tools API and enables the import of information and the selective
Figure 2. Example of an application software (ASW) component and
update of HW/SW interface model artifacts. This enables round-trip
configurations of a software signal interface. engineering of HSI definition within the spreadsheet and MDB tool.

Basic SW and HW Module Modeling Framework Spreadsheet Template

Special basic software (BSW) and hardware module representations The spreadsheet template defines the structure of the data
are assigned to establish links to the underlying basic software and representation in a project specific customizable way. This, on one
hardware layers. The AUTOSAR architectural approach ensures hand, enables a practicable and intuitive way of engineering HSI
hardware-independent development of application software modules definitions with spreadsheet tools and transformation to a reusable
until a very late development phase and therefore enables application and version able representation in the MDB tool. On the other hand,
software developers and basic software developers to work in this approach unifies the project-dependent process for HSI
parallel. The hardware profile allows a graphical representation of definitions across the variety of different projects and contributing
hardware resources (such as ADC, CAN), calculation engines (core), partners without requiring exactly the same development tools or
and connected peripherals that interact with the software. This processes in place. Thirdly, the machine- and human-readable
enables the mapping of tasks to a specific core and establishment of a notation of a spreadsheet ensures a cost- and time-saving alternative
valid scheduling in a later development phase. Furthermore, the to usually complex special-purpose tools. Figure 4 depicts the
profile enables an intuitive graphical way of establishing software project-independent template structure for HSI definition data
and hardware dependencies and a hardware-software interface (HSI), preparation.
as required by ISO 26262. Software signals in BSW modules can be
linked to HW port pins via dedicated mappings. This on one hand SW/SW Interface Generator
enables the modeling and mapping of HW specifics and SW signals,
see figure 3. On the other hand, this mapping enables traceable links The last part of the presented approach is the SW/SW interface
to port pin configurations. generator. This dll- based MDB-tool extension generates .c and .h
files defining SW/SW interfaces between application software signals
HSI Definition Exporter and basic software signals from the modeled HSI artifacts. In
addition this generation eliminates the need for manual SW/SW
The HSI exporter (a MBD-tool extension) establishes an API link to interface generation without adequate syntax and semantic support
spreadsheet tools and enables the export of modeled HW/SW and ensures reproducibility and traceability of these configurations.
interfaces to spreadsheet documents. This API link ensures freedom
from version dependence of the specific spreadsheet tool.
Furthermore, the MBD-tool extension is developed in the form of a
dll class library, which provides means for reuse by multiple
programs and ensures MDB-tool independence of the exporter.

Page 4 of 7
 of HSI definitions, available as graphical HSI model and spreadsheet
and automatically generates code configurations. Regarding the
SW/SW Interfaces on the ASW layer, consistency checks for the 32
output interfaces and 54 input interfaces ensure point-to-point
consistency of the signal routing. For 9 definable features per signal,
this adds up to 774 definitions, which are automatically checked for
consistency with this approach.

The actual HW/SW interface, mapping of BSW signals to HW pins,

also consists of 19 interfaces for this specific SW architecture. This
mapping includes 23 settings per mapping and can be automatically
exported to the spreadsheet tool.
In case of changes of the HSI mapping within the spreadsheet, e.g.
due to necessary pin reconfiguration, this information can be kept
consistent with the model-representation via the importer
functionality. This ensures actuality of development artifacts and
simplifies tracing of development decisions. Table 2 sums up the
additional features for the BMS use-case supported by the presented
approach and provides an overview of the amount of data affected by
each iteration step.

Figure 4. Example of a project-independent spreadsheet template structure for Table 2. Additional features provided by the approach and number of presence
HSI definition. for the BMS use-case

Automatically extracted settings to Excel 437

Application of the HSI Definition Approach
Consistency checks of ASW mappings 54

In order to evaluate the approach, an automotive use-case of a central Modeled ASW artifacts 10 modules + 86 signal ports
control unit (CCU) for a battery management system (BMS) Modeled BSW artifacts 7 modules + 38 signal ports
prototype for (hybrid) electric vehicle has been chosen. Project- Modeled HW/SW interface artifacts 19 HW pins + 19 pin configurations
specific details have been abstracted for reasons of commercial
sensitivity. Generated ASW/BSW mappings 33 LoC

Figure 5 shows a generalized representation of the CCU SW

architecture. As can be seen from the picture, 10 SW modules on the
ASW layer and 7 SW modules on the BSW layer have been defined. Summary
Table 1 summarizes the number of interfaces module and artifacts
representing the CCU SW architecture. This paper presented a tool approach for ISO 26262 aligned
hardware-software interface definition and a brief evaluation of the
Table 1. Summary of model artifacts representing the CCU SW architecture, approach for a BMS use-case.
required to model the BMS HSI definition. The approach combines the versatility and intuitiveness of
spreadsheet tools and the properties of MDB tools (e.g. different
Number of ASW module 10 views, levels of abstraction, central source of information, and
Number of BSW modules 7 information reuse) in a bidirectional way. This, on one hand, enables
a practicable, tool-independent, and intuitive way of engineering HSI
Number of ASW module inputs 54
definitions with spreadsheet tools and transforms the generated
Number of ASW module outputs 32 information to a reusable and version-able representation in the MDB
SW/SW interfaces on ASW layer 48 tool.
Amount of ASW/BSW interfaces 19
On the other hand, this approach unifies the project-dependent
process for HSI definitions across the variety of different projects and
Amount of HW/SW interfaces 19 contributing partners without requiring exactly the same development
tools or processes in place.
Thirdly, the machine- and human-readable notation of spreadsheets
As can be seen in table 1, 19 ASW/BSW interfaces (7 input and 12 ensures a cost- and time-saving alternative to usually complex
output interfaces) need to be defined. This definition adds up to more special-purpose tools. This facilitates collaboration especially for
than 30 lines of code (LoC) that can be generated automatically with small budget projects, projects with small and medium-sized
the presented approach into interface.c and interface.h files. companies or research projects, and collaboration with academic
partners.
Key aspects for ISO 26262 aligned HSI definition are correct,
consistent, and complete interface descriptions. Furthermore, Finally, the approach is capable of defining an ISO 26262 compliant
evidences of correct implementation of these interfaces are required. HSI definition and enables automatic derivation of basic software
This can be challenging in case of concurrent HW and SW configurations according to the HSI definition.
development and cross-dependencies of asynchronous update
intervals. Therefore, the presented approach provides a single source

Page 5 of 7
 Support for Programming Languages and Operating Systems,
doi:10.1145/2150976.2151011.
7. AUTOSAR Development Cooperation. " AUTOSAR
AUTomotive Open System Architecture,"
http://www.autosar.org, 2014.
8. Cimatti, A. and Tonetta, S.," A Property-Based Proof System for
Contract-Based Design," Proc. 36th EUROMICRO Conference
on Software Engineering and Advanced Applications, 2012.
9. Johansson, R., "Safety Contract Based Design of Software
Components", ISSREW, 2013, 2013 IEEE International
Symposium on Software Reliability Engineering Workshops
(ISSREW), 2013, doi:10.1109/ISSREW.2013.6688922.
10. Damm, W., Hungar, H., Josko, B., Peikenkamp, T. and Stierand,
I.,"Using Contract-Based Component Specifications for Virtual
Integration Testing and Architecture Design," DATE, 2011,
Design, Automation & Test in Europe Conference & Exhibition,
doi:10.1109/DATE.2011.5763167.
11. Bryans, J., Payne, R., Holt, J. and Perry, S.," Semi-Formal and
Formal Interface Specification for System of Systems
Architecture," Systems Conferecne (SysCon), 2013, ISBN 978-
1-4673-3107-4, doi:10.1109/SysCon.2013.6549946.
12. Macher, G., Armengaud, E. and Kreiner,C. ," Automated
Generation of AUTOSAR Description File for Safety-Critical
Software Architectures, " Lecture Notes in Informatics, 2014.
13. Chen, D., Johansson,R., Loenn,H., Papadopoulos,Y., Sandberg,
Figure 5. Generalized representation of the BMS software architecture; A., Toerner, F. and Toerngren, M., " Modelling Support for
subdivided into basic software modules and application software modules. Design of Safety-Critical Automotive Embedded Systems,"
SAFECOMP 2008, 2008.
Key aspects for ISO 26262 aligned HSI definition are correct, 14. Rajan, A. and Wahl, T., " CESAR – Cost-efficient Methods and
consistent, and complete interface descriptions. This is in particular Processes for Safety-relevant Embedded Systems, " Springer
crucial in case of concurrent HW and SW development and Wien, Rev, ISBN 978-3-7091-1386-8, doi:10.1007/978-3-7091-
synchronization of HSI changes and updates. By automatic 1387-5.
bidirectional updating of the information resources (model and 15. Broy, M., Feilkas, M., Herrmannsdoerfer, M., Merenda, S. and
spreadsheet) and automatic generation of code, the presented Ratiu, D., " Seamless Model-based Development: From Isolated
approach minimizes manual work efforts and improves traceability of Tool to Integrated Model Engineering Environments, "
HSI specification to code implementation. This helps to simplify Proceedings of the IEEE Volume 98 Issue 4, 2010,
concurrent development of software and hardware across domain, doi:10.1109/JPROC.2009.2037771.
company, and tool borders. 16. Fabbrini, F., Fusani, M., Lami, G. and Sivera, E., "Software
Engineering in the European Automotive Industry:
References Achievements and Challenges," COMPSAC, 2008, 2013 IEEE
37th Annual Computer Software and Applications Conference,
doi:10.1109/COMPSAC.2008.140.
1. Riel, A., Bachmann, O., Dussa-Zieger, K., Kreiner, C.,
17. Macher, G., Armengaud, E., and Kreiner, C., "Bridging
Messnarz, R., Nevalainen, R., Sechser, B., smf Tichkiewitch, S.
Automotive Systems, Safety and Software Engineering by a
EU Project SafEUr - Competence Requirements for Functional
Seamless Tool Chain," Proceedings European Congress
Safety Managers. In EuroSPI Proceedings, volume 301 of
Embedded Real Time Software and Systems, 2014.
Communications in Computer and Information Science, pages
253–265. Springer, 2012.
2. The International Organization for Standardization (ISO), "Road Contact Information
Vehicles Functional Safety Part 1-10," ISO 26262, 2011.
3. Messnarz, R., Kreiner, C., Bachmann, O., Riel, A., Dussa- Georg Macher
Zieger, K., Nevalainen, R., and Tichkiewitch, S. Implementing AVL List GmbH
Functional Safety Standards Experiences from the Trials about Powertrain Engineering – Research & Development
Required Knowledge and Competencies (SafEUr). In Systems, Graz University of Technology
Software and Services Process Improvement, volume 364 of Institute for Technical Informatics
Communications in Computer and Information Science, pages Tel.: +43 316 787 2974
323–332. Springer Berlin Heidelberg, 2013. [email protected]
4. Jerraya, A. and Wolf, W., "Hardware/Software Interface http://www.avl.com
Codesign for Embedded Systems," Computer, vol.38, no. 2, pp. http://iti.tugraz.at/
63-69, February 2005, doi:10.1109/MC.2005.61.
5. Kecheng, H. and Xie, F.," Componentizing Hardware/Software
Interface Design, " DATE 2009, ISBN 978-3-9810801-5-5
6. King, M., Nirav, D. and Arvind, "Automatic Generation of
Hardware/Software Interfaces," ASPLOS 2012: Proceedings of
the Seventeenth International Conference on Architectural

Page 6 of 7
Harald Sporer Definitions/Abbreviations
Graz University of Technology
Institute for Technical Informatics
ECU Engine control unit
Tel.: +43 316 873 6409
[email protected]
http://iti.tugraz.at/ HSI Hardware-software interface

Eric Armengaud MDB Model-based development

AVL List GmbH
Powertrain Engineering – Research & Development AUTOSAR Automotive open system
Tel.: +43 316 787 6945 architecture
[email protected]
http://www.avl.com SoC System on chip

Christian Kreiner SW Software

Graz University of Technology
Institute for Technical Informatics ASW Application software
Tel.: +43 316 873 6408
[email protected] BSW Basic software
http://iti.tugraz.at/
HW Hardware
Acknowledgments
VFB Virtual function bus
The authors would like to acknowledge the financial support of the
"COMET K2 - Competence Centers for Excellent Technologies BMS Battery management system
Programme" of the Austrian Federal Ministry for Transport,
Innovation and Technology (BMVIT), the Austrian Federal Ministry CCU Central Control Unit
of Economy, Family and Youth (BMWFJ), the Austrian Research
Promotion Agency (FFG), the Province of Styria, and the Styrian Lines of Code
LoC
Business Promotion Agency (SFG).

We are grateful for the contribution of the SOQRATES Safety AK

experts and the expertise gained in SafEUr professional trainings.

Furthermore, we would like to express our thanks to our supporting

project partners, AVL List GmbH, Virtual Vehicle Research Center,
and Graz University of Technology.

Page 7 of 7

View publication stats