This version is available at https://doi.org/10.14279/depositonce-9868
This work is licensed under a CC BY-NC-ND 4.0 License (Creative
Commons Attribution-NonCommercial-NoDerivatives 4.0 International). For
more information see https://creativecommons.org/licenses/by-nc-nd/4.0/.
Terms of Use
Martin, H., Ma, Z., Schmittner, C., Winkler, B., Krammer, M., Schneider, D., Amorim, T., Macher, G., &
Kreiner, C. (2020). Combined automotive safety and security pattern engineering approach. Reliability
Engineering & System Safety, 198, 106773. https://doi.org/10.1016/j.ress.2019.106773
Helmut Martin, Z. Ma, Christoph Schmittner, Bernhard Winkler, Martin
Krammer, Daniel Schneider, Tiago Amorim, Georg Macher, Christian
Kreiner
Combined automotive safety and security
pattern en
g
ineerin
g
approach
Accepted manuscript (Postprint)Journal article |
Combined Automotive Safety and Security Pattern
Engineering Approach
H. Martin1, Z. Ma2, Ch. Schmittner3, B. Winkler1, M. Krammer1, D.
Schneider4, T. Amorim5, G. Macher6, Ch. Kreiner6
Graz and Vienna, Austria - Kaiserslautern and Berlin, Germany
Abstract
Automotive systems will exhibit increased levels of automation as well as ever
tighter integration with other vehicles, traffic infrastructure, and cloud services.
From safety perspective, this can be perceived as boon or bane - it greatly
increases complexity and uncertainty, but at the same time opens up new op-
portunities for realizing innovative safety functions. Moreover, cybersecurity
becomes important as additional concern because attacks are now much more
likely and severe. However, there is a lack of experience with security concerns
in context of safety engineering in general and in automotive safety departments
in particular. To address this problem, we propose a systematic pattern-based
approach that interlinks safety and security patterns and provides guidance with
respect to selection and combination of both types of patterns in context of sys-
tem engineering. A combined safety and security pattern engineering workflow is
proposed to provide systematic guidance to support non-expert engineers based
on best practices. The application of the approach is shown and demonstrated
by an automotive case study and different use case scenarios.
Keywords: ISO 26262, SAE J3061, Engineering workflow, Safety pattern,
Security pattern, Automotive
1Virtual Vehicle Research Center
2AVL List GmbH
3Austrian Institute of Technology GmbH
4Fraunhofer IESE
5Technische Universit¨at Berlin
6Graz University of Technology
Preprint submitted to Journal of L
A
T
EX Templates October 7, 2019
This is the Accepted Manuscript of: Martin, H.; Ma, Z.; Schmittner, C.; Winkler, B.; Krammer, M.; Schneider,
D.; Amorim, T.; Macher, G.; Kreiner, C. (2020). Combined automotive safety and security pattern engineering
approach. Reliability Engineering & System Safety, 198, 106773. https://doi.org/10.1016/j.ress.2019.106773
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International
License, https://creativecommons.org/licenses/by-nc-nd/4.0/.
1. Introduction
Future applications in the automotive domain will be highly connected.
They will rely on interacting functionalities exchanging data via various net-
working channels, and storing or receiving their operational data in or from the
cloud. On the one hand, there is an enormous potential in these new types5
of cyber-physical system (CPS) applications and services, which are bound to
revolutionize the automotive domain, as we know it today. On the other hand,
ensuring safety and security of next generation automotive systems is a signifi-
cant and comprehensive challenge that needs to be addressed before promising
visions can become reality and an economic and societal success story. Today,10
practitioners in the automotive domain are well experienced to deal with safety
aspects during the development of regular automotive systems, because a safety
standard has been available since 2011. However, there is a lack of knowledge on
how to handle related security aspects, which strongly gain importance given the
trend towards CPS. The required security knowledge is either just non-existent,15
or, maybe even more often, distributed over different organizational units in a
company and thus not easily accessible. Furthermore, there is no automotive
specific security standard available at the moment.
Given the tight interconnection and the mutual impact of safety and security
aspects, there is a need for a combined engineering approach enabling safety20
and security co-engineering. Moreover, given the present lack of experience in
safety and security co-engineering, we think that providing additional guidance
to engineers would be highly beneficial.
The safety domain has collected valuable experience in using model-based
approaches for safety analysis [1] and integration of safety engineering with25
systems engineering by using a shared model as common viewpoint [2]. We
extend this towards security and show how model-based engineering can support
system, safety and security engineering.
In this paper, we specifically focus on the proper and due consideration of
2
the security aspect within the safety engineering life cycle, which is one particu-30
larly urgent problem related to the aforementioned challenge. Consequently, we
propose a systematic pattern-based and ISO 26262-oriented approach for safety
and security co-engineering in the automotive domain. Through the use of pat-
terns, we aim to close the security knowledge gap by harvesting its manifold
benefits: conservation and reuse of design knowledge, best practices and tested35
solutions, reuse of architectural artifacts enabled by abstraction, cross-domain
exchange of solution concepts, etc. Apart from the systematic interlinking of
safety and security patterns, we elaborate how these patterns can be specified
and maintained.
This paper is based on the conference paper “Systematic Pattern Approach40
for Safety and Security Co-engineering in the Automotive Domain” from Amorim
et. al [3] presented at the main track of SafeComp20177in Trento/Italy. The
figures in the methodology part and in the battery use case are taken from
that publication. For this journal paper we provide more details regarding the
pattern description and more insight regarding the co-engineering methodology.45
Furthermore, we extended the application of the methodology on the battery
management system case study regarding support of pattern engineering by
further use case scenarios and emphasizing Model-based Systems Engineering
(MBSE).
2. Background and Related Work50
This section provides an overview about architectural patterns in general,
safety patterns, security patterns, safety and security co-engineering, and cur-
rent relevant automotive guidance for safety and cybersecurity.
2.1. Relevant Automotive Guidance for Safety and Cybersecurity
ISO 26262 (“Road vehicles −Functional safety”) [4] is an automotive domain-55
specific safety standard. It provides a structured and generic approach for the
7http://safecomp17.fbk.eu/
3
complete safety life cycle of an automotive E/E system including design, devel-
opment, production, service processes, and decommissioning. ISO 26262 recom-
mends requirements and techniques for system, software, and hardware design
to achieve functional safety for E/E systems. An Automotive Safety Integrity60
Level (ASIL) is used as a central metric for determination of development efforts
required for the entire safety life cycle. For instance, the usage of established de-
sign patterns is recommended for all ASIL levels for each sub-phase of software
development, as described in Subsection 4.4.7 in Part 6 of ISO 26262. Concern-
ing security, the first edition, released in 2011, does not consider it explicitly65
neither there is any support or guidance. The second edition ISO 26262 (released
by end of 2018) contains only some guidance where an interaction between safety
and security may occur from a safety perspective. Part 4 & 6 for system and
software engineering point for the requirement and architecture consolidation
to the need to coordinate safety and security requirements. In addition Part 270
for the safety management requires communication channels between functional
safety and disciplines related to functional safety like cybersecurity. We present
here an approach which uses model-based engineering and patterns to formalize
the interaction between safety and security for the system design and show an
approach to address the new requirements regarding interaction.75
SAE J3061 [5] is a cybersecurity process framework for secure development
life cycle tailored to the automotive domain by using a corresponding V-Model,
as defined in ISO 26262. In SAE J3061, safety and security interaction points
were defined to coordinate the two engineering processes. In 2017 development
of ISO/SAE 21434 (“Road vehicles −Cybersecurity engineering”) [6] has been80
started as a joint project between ISO and SAE. The goal is to develop a cyber-
security engineering standard for road vehicles that includes requirements for
cybersecurity process and a common language for communicating and manag-
ing cybersecurity risk among stakeholders based on ISO 26262 and SAE J3061.
It is planned to include similar guidance for the interaction between safety and85
cybersecurity from a cybersecurity perspective.
4
2.2. Safety and Security Co-Analysis and Co-Engineering
Safety and security aspect must be considered in a holistic way due to tighter
interactions between safety and security in automotive CPS. In this paper, safety
& security co-analysis refers to methods and techniques that can be used to iden-90
tify safety hazards and security threats in a joint approach. Co-analysis includes
activities in the early stage of the development life cycle, e.g. in the require-
ments engineering as well as the design phase. Safety & security co-engineering
refers to engineering activities that consider both safety and security and their
interactions in the development life cycle like trade-off analysis or shared testing,95
verification and validation. Furthermore, co-engineering considers all phases of
the life cycle, in which co-analysis is an integral part.
In the context of automotive domain, existing analysis method Hazard Anal-
ysis and Risk Management (HARA), which is standardized in ISO 26262 for
safety, can be extended with Threat Analysis and Risk Assessment (TARA)100
method, as mentioned in SAE J3061 to identify cybersecurity risks [7]. Other
proposals include Failure Mode and Vulnerability Effect Analysis (FMVEA) [8]
and Security Aware Hazard Analysis and Risk Assessment (SAHARA) [9] that
aim at combining both safety and security analysis in parallel. A safety and
security co-engineering approach should include all engineering activities in the105
automotive system development life cycle according to relevant standards such
as ISO 26262 and SAE J3061 based on the V-Model [10]. There are different
approaches, partially supported by projects, to address and define a framework
for co-engineering. One major approach is based on work done in SESAMO8
on interaction points, which is currently refined in the AQUAS9project. The110
generic concept of interaction points is similar to our approach, defining points
in the system engineering life cycle where engineering teams from different do-
mains need to interact in order to build a system [11]. A systematic pattern
based interaction between safety and security can be considered as a interaction
8http://sesamo-project.eu
9https://aquas-project.eu
5
point or, in the term of iterative refinement, an interaction cycle. Besides inter-115
action point based co-engineering approaches there are also other approaches,
like for example the approach which is developed in the AMASS10 project,
which aims at a complete replacement of established development processes by
an co-engineering process.
2.3. Architectural Patterns120
Patterns are used to collect and organize solutions for similar problems with
a general and universal solution. A well-known and proven solution for a specific
problem is generalized so that it can be reused for similar recurring problems in
other projects. Alexander describes the concept of using architecture patterns
to solve similar problems in different projects [12]. The concept of patterns is125
used in many different domains including hardware and software. A good and
very well-known reference is the book by Gamma et al. [13] (also known as the
Gang of Four), which had a significant impact on making the pattern approach
popular for software development. The book includes some general background
and concepts as well as a collection of concrete patterns for object-oriented130
software design.
The state-of-the-art provides a few dozen safety architecture patterns [14][15],
with some being just a variation of simpler ones. Armoush introduced in his
PhD thesis [14] new safety patterns and provides a collection of existing safety
patterns and a characterization of the main pattern representation attributes for135
embedded systems patterns (e.g. Name, Type, ID, Abstract, Context, Problem,
Structure,). These patterns are mostly based on the work of Douglas [16][17] for
hardware patterns and on Pullum [18] for software fault tolerance techniques
brought into pattern notation for software patterns. Safety patterns usually
include some kind of hardware redundancy, multiple channels with voters, or140
sanity checks [15]. They can address software or hardware issues and they allow
systems to remain fully functional or to bring them to a safe state. Describing
10https://www.amass-ecsel.eu
6
existing patterns, but the ones used in the presented case study, is out of the
scope of this work.
Security engineering is an iterative and incremental process. Security pat-145
terns can be seen as the essence of sound security designs and best practices
from an existing body of knowledge that can be used to solve security problems
in new scenarios. During the security engineering process, security patterns
can be used in requirements analysis and design to eliminate security flaws and
provide additional information for security validation.150
Security patterns have attracted the attention of both academic researchers
and industry [19]. The main focus of existing work is on the construction (includ-
ing representation, classification, and organization) and application of security
patterns. Security patterns are represented as textual templates or combined
with UML models, in a hierarchically layered architecture or in a search-able155
pattern library. Security patterns have been proposed for requirements engineer-
ing, software system design such as web services, and Service-Oriented Architec-
tures [20]. Open Security Architecture is a community-based online repository
of security control patterns based on the ISO 27000 information security stan-
dard family for enterprise IT systems, in which patterns are represented as text160
and graphical architecture designs in a consistent template. In recent years,
security patterns have also been proposed for CPS [21].
2.4. Model-based Systems Engineering
Model-Based Systems Engineering (MBSE) is an efficient approach to spec-
ify, design and analsze complex systems. Estefan et. al [22] provide an overview165
of MBSE methodologies and cover a collection of related processes, methods,
and tools used to support the discipline of systems engineering and the role of
the system modeling language SysML in that context. SysML is a semi-formal,
general purpose modeling language. It is based on Unified Modeling Language
(UML), constructed for systems engineering applications and is standardized170
7
by OMG11 [23]. SysML concepts concern requirements, structural modeling,
and behavioral constructs. New diagrams include a requirement diagram and
a parametric diagram and adjustments of UML activity, class, and composite
structure diagrams. The three main diagram types of SysML are requirement di-
agram, block definition diagrams and internal block diagrams. The requirement175
diagram provides cross cutting relationships between requirements and system
models; the structural diagrams are block definition diagrams, internal block di-
agrams, package diagrams, and parametric diagrams; the behavioral diagrams
are use case, state machine, activity diagrams, and sequence diagrams. [24]. We
use in our approach the block definition diagram for the modeling of the system180
and the patterns. Model-based approaches are increasingly used for safety, this
starts from safety analysis based on system models to the integration of safety
artifacts into the system modeling [25]. Benefits of such an approach are the
consistency between models, since there is only one system model with different
views. There is also an ongoing development to extend Model-Based Systems185
Engineering towards security [26].
3. Methodology
Although patterns address specific problems, the context in which a pattern
is applied influences how it should be applied. Therefore, practitioners require
systematic guidance when using patterns to tackle safety and security problems,190
i.e. more than just a catalog of patterns is needed. We thus propose a model-
based safety and security pattern engineering workflow that aims at combining
the two engineering processes for pattern identification and design and allows
for the necessary interaction and balancing of safety and security concerns.
In addition, in order to support the described process in an optimal way, we195
introduce some specific extensions to the description of both types of pattern.
These extensions focus on the links between the two engineering domains and
11http://www.omg.org/
8
are thus a means to bridge the gap and come closer to a real co-engineering
approach to support analysis and argumentation.
3.1. Pattern Description200
With respect to safety pattern, extensions have been proposed to support
engineers in adapting their assurance case argumentations after a pattern has
been applied. Argumentation fragments, specified in Goal Structuring Notation
(GSN), could, for instance, be provided specifically for each pattern [27, 15] .
For the presented approach we build on these safety pattern with argumen-205
tation guidance and propose to use something similar for security. However, in
order to better support the interaction between safety and security and to fos-
ter co-engineering, we further enrich the descriptions with pointers to respective
safety or security weak points related to the pattern and suggest application of
corresponding analyses to investigate these issues and generate evidences for the210
argumentation. In general, patterns act as a central base of knowledge, which
should be maintained based on the lessons learned during their application. On
the one hand positive examples and scenarios can be referred and on the other
hand negative examples, where the use of a pattern raised new and unwanted
issues, should be documented as well.215
Each pattern contains a general pattern description, which covers pattern
name, pattern type, context, problem, forces solution, graphical representation.
A generic pattern template is shown in Figure A.9.
The safety pattern adopts the generic template, correspondingly describes the220
safety content and additionally augments it with respect to security aspects.
Key constituents of the safety pattern are:
•GSN fragment of safety pattern [15]
•General security implications (e.g. typical security properties that might
interact with the pattern)225
•Guidance wrt. security analysis (e.g. in a voter pattern, a promising
attack vector might be going through the voter, thus analysis of the voter
9
is recommended)
•GSN fragment of security implications [27]: The GSN fragment reflects the
bullets above in a generic way, so that the integration of these security con-230
siderations into the argumentation is simplified/guided to a certain extent.
We design the security pattern to follow the same approach as the safety pat-
tern, they adopt the generic template, describe the security content as well as
additional information regarding potential safety implications. Key constituents235
of the security pattern are:
•GSN fragment of security pattern
•General safety implications (e.g. typical safety properties that might inter-
act with the pattern such as hard real time requirements and encryption)
•Guidance wrt. safety analysis (e.g. introducing additional HW compo-240
nents in a functional path additional random HW failure have to be taken
into account)
•GSN fragment of safety implication: The GSN fragment of the pattern
reflects the bullets above in a generic way, so that the integration of the
security pattern (as well as auxiliary safety analyses / evidences) is sim-245
plified/guided to a certain extent.
Appendix A of this paper provides examples of a safety pattern (see Figure A.10)
and security pattern (see Figure A.11).
3.2. Generic Combined Pattern-based Engineering Workflow
The Generic Combined Pattern-based Engineering Workflow is the approach250
proposed in this paper to guide engineers selecting and applying safety and se-
curity patterns to develop safe and secure systems/products. This workflow is
meant to be used in unison (and tightly integrated) with the usual safety and
security engineering approaches. It therefore does not substitute established ap-
proaches but rather enhances them with further tasks. The approach is suitable255
to be used with existing patterns. The workflow can take place at the different
10
Figure 1: Generic combined pattern-based engineering workflow
development phases of the V-Model in framework of ISO 26262 [4] where design
and specification are involved: concept phase, system level, hardware level and
software level.
For example during the system design the Functional and Technical Concept260
are fully developed and both are used as input for the workflow.
The workflow is divided into three main phases happening one after the
other in a waterfall fashion (cf. Figure 1): Safety Pattern Engineering, Security
Pattern Engineering, and Safety and Security Co-Engineering Loop. In the first
two phases specific teams are involved: Safety Pattern Engineering is performed265
by systems and safety engineers, and Security Pattern Engineering is performed
by systems and security engineers.
The output of the workflow is then consumed by the next phases of the V-
Model, namely Product Development: Hardware level and Software level.
270
The rationale for this is that the approach explicitly focuses on security for
safety (i.e., safety concerns are the main engineering drivers) and that security
should start working when the first safety architecture is almost defined.
In general, further changes in the architecture might open new vulnerability
11
Figure 2: Safety pattern engineering and security pattern engineering tasks
points or might not be properly covered by mechanisms already implemented.275
However, it has to be taken into account that security measures can influence
system properties that can alter safety.
For this reason, we introduce the Safety and Security Co-Engineering Loop,
the third phase of the workflow. In this phase all involved disciplines (systems,
safety, and security engineers) work together in a joint approach. The loop280
prevents safety-motivated changes from creating unforeseen vulnerabilities and
security-motivated changes from jeopardizing safety characteristics of the sys-
tem. Each of these three phases will be described in the next subsection to
provide a more detailed overview of the approach.
3.3. Safety Pattern Engineering285
Safety Pattern Engineering involves safety-related tasks and is composed of
three main tasks Perform Safety Analysis,Select Safety Pattern,Apply/Instantiate
Safety Pattern (cf. Figure 2), which will be described in the following para-
graphs.
Perform Safety Analysis. As described above, patterns are used to tackle spe-290
cific problems; therefore, we need to have a good understanding of the system
and the context in order to select and apply patterns appropriately. The work-
flow starts with established safety engineering approaches and techniques that
need to be carried out until Safety Requirements (Functional or Technical) are
12
available (i.e. Hazard and Risk analysis, FMEA and FTA to break down higher295
level to lower level requirements).
Select Safety Pattern. The decision about which pattern best fits a specific sys-
tem should be analysed taking into account the problem to be addressed (typi-
cally ensuring identified Safety Requirements) and the context of the system. In
the proposed pattern template, particularly the information regarding pattern300
type, context, problem, forces and solution are now to be considered. Besides,
there are a few trade-offs that one additionally needs to take into consideration
when choosing an architectural pattern, such as costs (hardware, development
effort) or standardization. Current state-of-the-art [14, 16, 17] provides many
patterns with detailed information about the impact in the system in the view305
of different dimensions (e.g. Cost, Reliability, Safety, Security), but some work
is obviously required to create a comprehensive pattern catalogue that is fully
in line with the templates proposed in this article. At any rate, there might
always be cases that no pattern is suitable for the discovered problems and the
engineer needs to come up with an ad-hoc solution.310
Apply/Instantiate Safety Pattern. Instantiating an architectural pattern for a
system typically implies certain adjustments to tailor the pattern towards the
existing system architecture and the problem to solve. In contrast, using the
pattern as-is is usually not possible, because they have been developed out of
context and must thus be application and context agnostic. However, the pat-315
terns we propose (as described above and illustrated in the Appendix) provide
comprehensive guidance regarding the activities to be performed as well as aux-
iliary material such as argumentation fragments to support the engineers in the
best possible way. In addition, our safety pattern provide guidance with respect
to security implications, highlighting potential weak points and providing corre-320
sponding analysis support as well as argumentation support in form of a security
related GSN fragment. In summary, the pattern instantiation does not only re-
sult in a revised system architecture (now including the elements modeled by
the pattern) but also in an augmented safety and security argumentation bol-
13
stered by corresponding analyses. The updated system architecture as well as325
the augmented analyses and argumentations are the prerequisites for the next
task.
3.4. Security Pattern Engineering
In the previous phase, the architecture was updated with safety measures,
the safety argumentation has been advanced and security implications of the330
safety measures have been analysed. In the Security Pattern Engineering phase,
the architecture will be further analysed with regard to security vulnerabilities.
Corresponding pointers might be given directly by the descriptions (security
analysis and security-related GSN fragments) of the safety pattern selected in
the safety pattern engineering phase. Open weak points are to be addressed by335
applicable security patterns. The output of this phase will be a secure architec-
ture.
Perform Security Analysis. In this step, Security Engineering is performed on
the existing system context such as functional requirements, results of Safety
Engineering, and intermediate architectural design of the system, including the340
safety patterns. Established Security Engineering methods and techniques such
as attack surface analysis, attack trees, and threat modeling can be used to
identify vulnerabilities and threats. The results of this task leads to security
measures that either mitigate potential threats or reduce the risks to an ac-
ceptable level. Special attention is given to vulnerabilities introduced by safety345
patterns.
Select Security Pattern. The security engineers should give priority to the se-
lection of re-usable security solutions from well-established security patterns for
mitigating the security risks. If multiple security patterns are available, the se-
lection of a security pattern is then a design decision that optimizes cost-benefit.350
Similar to the selection of safety patterns, if no security pattern is available, an
ad-hoc solution is applied.
14
Apply/Instantiate Security Pattern. In this step, the instantiated security pat-
tern is incorporated into the existing system architecture design while taking
into consideration context of the system. The structure of the pattern and the355
instantiation approach is thereby similar to the safety pattern. In particular, be-
yond guidance regarding the application of the security pattern and correspond-
ing security argumentation support, there are also pointers regarding potential
safety implications which might play a role in the subsequent co-engineering
loop.360
3.5. Safety and Security Co-Engineering Loop
After the initial two phases of the Pattern Engineering Workflow, the Safety
and Security Co-Engineering Loop starts. The identified patterns cover safety
and security measures defined by specific requirements. Each safety and security
measure should pass through the co-engineering loop to approve their adequate365
co-existence. Guidance with respect to the interrelationships is given by the
pattern descriptions.
In this phase, lightweight versions of safety pattern engineering and security
pattern engineering take place one after the other until no extra modification is
required in the architecture. The fact that they are performed as a lightweight370
version means that the focus is on checking those aspects that experienced alter-
ation and their respective influence on the overall system. The loop starts with
the safety pattern engineering task requiring safety engineers to analyse how
the newly added security patterns might impact the system safety. Some secu-
rity architecture strategy might impair, for example, the communication time375
between components, causing a command to arrive late. Also in this task, the
results of the first security pattern engineering phase help the safety engineers
to identify further points of failure that could be caused by an attack. The ini-
tial safety pattern might require some modification to add extra safety. On the
other hand, if the newly proposed safety mechanisms imply new vulnerabilities380
or changes in the attack surface, the security engineers should detect, assess,
and propose new solutions. This is what happens during the security pattern
15
engineering performed in the lightweight version. This goes on like a cycle and
stops when the system fulfills the desired safety and security requirements. Up-
dating supporting documentation and updating the architecture are also tasks385
to be performed.
In the co-engineering loop iterative activities have been defined, which are
described in the following and shown in a flow diagram in Figure 3 (Sx...Stepx,
D...Decision):
(S1.) Safety Impact Analysis. After successful instantiation of the security pat-390
tern in the architecture, a safety impact analysis has to be performed. This
analysis should check what happens if the introduced security measures may
have any safety impact. But it is not only the safety failure of the security
measure, it is also the possibility that the presence of that security measure
modifies the way the failures of any other elements of the architecture propa-395
gate in a modified manner, i.e. a complete safety analysis of failure modes of
new/modified elements as well as redo safety analysis of other existing elements
regarding any impact on existing failure modes.
(S1.D) Decision: Is there an impact of Security on Safety?
(S1.D.a) Answer NO - Safe and Secure Concept available400
(S1.D.b) Answer: YES - Continue to with Co-Analysis
(S2.) Co-Analysis. Perform Co-Analysis for safety and security aspects by
methods, such as SAHARA or FMVEA for identification of effected elements
regarding new failure modes (safety) or new vulnerabilities (security).
(S3.) Harmonization. Joint engineering team elaborates and defines safety and405
security measures based on available patterns.
(S3.D) Decision: Is harmonization successful without any side-effect between
safety and security measures?
(S3.D.a) Answer: YES - A possible solution has been elaborated. All safety
and security requirements are covered without any contradiction (”freedom of410
16
Figure 3: Flow chart of co-engineering loop iteration
interference”). Safe and Secure Concept is available. →Continue to (S5.)
Argumentation.
(S3.D.b) Answer: NO - Proposals for different solutions are available. →
Continue to (S4.) Trade-Off.
(S4.) Trade-Off. Joint engineering team has to prioritize which aspect is more415
relevant and a trade-off between safety and security measures have to be chosen.
The trade-off can be supported by specific safety and security pattern, where a
different pattern may be chosen to handle that issue and a compromise has to
be achieved.
(S5.) Argumentation. The final activity of the loop will be Argumentation. In420
that task the safe and secure concept will be available and all rationals will
be collected to compile the final safe and secure argument of the elaborated
concept, that provides a piece to the Assurance Case.
4. Automotive Case Study
In the following section, the Combined Pattern-based Engineering Workflow425
is applied to an automotive case study, namely Electrified Hybrid Powertrain
17
Figure 4: [Left]: Automotive Battery Use Case |[Right]: Architecture with the safety pattern
applied
Battery Management System.
4.1. Use Case Description
Our automotive use case example of a connected electrified hybrid pow-
ertrain is a combination of one or more electric motor(s) and a conventional430
internal combustion engine, which is currently the most common variant of
hybrid powertrains. The variety of powertrain configuration options increases
the complexity of the powertrain itself as well as the required control systems,
which include software functions and electronic control units. With the inte-
gration of connectivity features, further novel vehicle functionalities and new435
business models can be discovered. Therefore, we focus on an integral part of
every connected hybrid powertrain, the battery management system (BMS),
and its functionalities related to the connection to the external world; in this
case especially the connections with the charging unit. In this section, we inves-
tigate a specific use case scenario of the connected hybrid powertrain: charging440
of the battery system by connecting it with an external charging unit. Figure 4
[Left] shows the most relevant elements: battery (including all battery modules),
BMS, CAN communication, charging interface, and external charging unit.
18
4.2. Application of the Approach
In this subsection, we apply the Combined Pattern-based Engineering Work-445
flow presented in the previous subsection in the use case scenario in an early
development phase called ”concept phase”.
The described approach to cover safety activities is based on the functional
safety standard ISO 26262 and in particular the parameters (e.g. severity, ex-
posure, controllability) used in HARA are taken from ISO 26262-part3, which450
covers the concept phase.
For security ISO/SAE 21434 [6] is still in development and SAE J3061 was
pushed back to work in progress. We use threat modeling as a well established
security analysis method for the automotive domain [28], [29], [30]. In order to
support a consistent engineering workflow we utilize a threat modeling add-in455
for Enterprise Architect (EA) [31] 12. In this approach a model of the system
is evaluated based on a formal description of threats to determine threats ap-
plicable to the analysed system. Different levels of the add-in are available.
Furthermore, the MBSE tool EA provides good user support and possibilities
for a built-in pattern mechanism. EA defines patterns as a group of collabo-460
rating objects or classes that can be abstracted from a general set of modeling
scenarios. Therefore, patterns are considered as an excellent means of achieving
re-use and building in robustness. However, pattern modeling inherently intro-
duces front-loading principles. A library of patterns needs to be built first, in
order to provide the engineer with a sufficient list of options to choose from.465
4.2.1. Safety Pattern Engineering
Perform Safety Analysis.We describe in the following a small summary of
the results of this task up to the level of Functional Safety Requirements:
Hazard: Wrong estimation of charging status.470
Comment: The battery of electric vehicles can be very dangerous in case of
12www.sparxsystems.eu
19
overcharging, even causing explosions. If the charging status of a battery is esti-
mated wrongly, extra energy might be supplied, leading to a hazardous situation.
Operational situation: Parking475
Comment: The hazard will only happen while charging, and this can only be
performed while the car is parked. This hazard might also occur while driving
when architectures with regenerative systems are considered.
Hazard classification: Severity: 3 — Exposure: 4 — Controllability: 2480
Resulting hazard ASIL: [C]
Safety goal: Estimate correct status of cycle while charging.
Safe state: “HV Battery disconnected” AND “Driver alerted”.
Functional Safety requirement: Detect failures and errors from BMS.
485
Select Safety Pattern. The results from Safety Engineering describe two pos-
sible safe states for the system that are compliant with the Safety goal. The
Disconnect HV battery measure would cut off the power supply, the source of
the hazard. The Alert driver measure would issue a warning to the driver.
The car will be in parking mode if the hazard occurs (operational situation:490
Parking); therefore, full functionality in case of fault occurrence is not required.
We should apply to the architecture a pattern that helps fulfilling the Func-
tional Safety Requirement Detect Failure and errors from BMS. We selected the
Monitor- Actuator Pattern [16] (cf. Figure 4 [Right]) which provides heteroge-
neous redundancy. This pattern adds to the architecture a monitoring channel495
that detects possible faults and triggers the primary channel to enter its fail-safe
state. The Monitor-Actuator Pattern is suitable to systems with low availability
requirements and addresses the problem of finding an appropriate mechanism
for detecting failures or errors without incurring higher costs.
Apply/Instantiate Safety Pattern. The Monitor-Actuator Pattern was instanti-500
ated as depicted in Figure 4. Only changes to the BMS component were made.
20
Figure 5: Threat modeling of architecture (Tool: Enterprise Architect 14 with ThreatGet
Plugin [31])
4.2.2. Security Pattern Engineering
Perform Security Analysis.In this context, Security Engineering follows
the initial definition of a safety pattern to identify potential security threats and
vulnerabilities in the design, and to assess the risks in order to find appropriate505
countermeasures and apply corresponding security patterns. In this example,
we use the threat modeling methodology [32], in which a system is modeled in
a Data Flow Diagram (DFD). When modeling the functional blocks from the
safety pattern (cf. Figure 4) in a DFD, a few transitions and extrapolations
occur.510
First, since threat modeling assumes that attacks happen when data flow
from one process (i.e., a software component that takes input and either pro-
duces output or performs an action) to another, the logic signal flows in the
safety pattern need to be translated into directional data flows according to
the software architecture implementing this safety logic. Therefore, additional515
components are added such as the CAN bus process, which represents the com-
munication bus in the in-car system. Second, the trust boundaries need to
be defined in the DFD in order to identify attacks originating from data flows
across trust boundaries. As a result, the Charging Interface (CI) is split into two
21
parts: an in-car CI and the corresponding interface at the charging station. The520
interface on the charging station is modeled as an external interactor outside
the In-car system trust boundary. There can be different levels of trust bound-
aries. In this case, we assume that attacks can only originate from outside the
In-car system boundary. Third, at the system level, security has an influence on
components beyond the scope of the safety pattern. Since the communication525
between the primary and monitor channel and the CI goes through the CAN
bus, and the powertrain unit is connected to the same bus, the security of the
CI also influences the security of the powertrain unit. Thus even though the
two safety modules cannot be attacked directly due to the unidirectional data
flows, there are risks that an attacker might use the system charging function530
to attack the powertrain unit. Figure 5 shows the modeled architecture in DFD
using the free cyber-security modelling addin for Enterprise Architect [31].
Asset: BMS software and its related functions and messages on the CAN
bus are the main assets
Threat: Attack CAN bus through in-car CI535
Comment: The communications from the external CI to the CAN bus is re-
sponsible for establishing and maintaining communications for charging control.
An attacker can use the in-car CI as an entry point by compromising the exter-
nal CI or tampering with the communications between the interfaces to inject
malicious content into the CAN bus.540
Impact: Safety impact of the identified threats on the assets.
Comment: The safety analysis defines the initial scope of the security analysis.
The impact analysis links the results from safety and security analysis. Table 1
gives an example of the outcome of the security impact analysis. The co-analysis
provides grounds for detailed security engineering requirements on the system.545
Security requirements: The security requirements are related to authenti-
cation, authorization, non-repudiation, accountability, data integrity, confiden-
tiality, privacy, and availability, which need to be further allocated to system
and component level during the design. In this example, we skip the assessment
of severity of the impact so we consider all safety impacts when deriving the550
22
Table 1: Security impact analysis
Asset Security impact Safety Impact
BMS soft-
ware
Integrity of BMS soft-
ware
Overcharging battery
system
CAN bus
communica-
tion
Availability of CAN
messages to their in-
tended ECUs
Disturbing ECU func-
tioning on the power-
train system
security requirements.
Select Security Pattern. During security design, other factors beside require-
ments such as available solutions, performance and cost need to be taken into
consideration. Since current CAN does not support encrypted and authenti-
cated communication, one possible solution is to add a security gateway between555
the external unit and the internal CAN bus as shown in Figure 6. The secu-
rity gateway is the application of the security pattern “firewall” that is placed
between an unprotected internal network and untrusted external entities when
communication to the outside is inevitable (see Figure A.11). The firewall pat-
tern is a basic security measure that controls incoming and outgoing network560
connections between a protected and an untrusted network. It provides net-
work access control that restricts which hosts can be accessed on the internal
network. Note that other security patterns can be applied as well. For example,
we might apply the ”security proxy” pattern, in which an entity on the com-
munication path between the charging station and the BMS software will not565
only translate different communication protocols (e.g. Ethernet to CAN), but
also authenticate the charging station and verify the validity of the communi-
cation. As a repeatable solution, the security gateway is not limited to the CI.
It can be applied to any communication between the CAN bus and untrusted
external devices. In general, the gateway controls the network access to the570
internal ECUs according to predefined security policies and can also inspect
23
Figure 6: Security Gateway as a security pattern (Tool: Enterprise Architect 14 with Threat-
Get Plugin [31])
packet content to detect intrusion attempts and anomalies. In this way, it adds
security protection and segments the system without fundamentally changing
the existing in-car system architecture.
Select/Instantiate Security Pattern. In Figure 6, we see the altered architecture575
with the Security Gateway module.
4.2.3. Safety and Security Co-Engineering Loop
Beyond the many benefits, a security gateway might introduce latency into
the communication or block critical messages due to false-positives, which is a
subject of safety impact analysis.580
Safety Impact Analysis. With the inputs from previous tasks we perform a
HAZard and Operability Study (HAZOP) analysis to identify potential anoma-
lies in the provision of the service controlling the CI (cf. Table 2). The focus is
thus on the changes performed to the architecture by the security engineers.
Based on the analysis we identified failure modes Omission and Late as585
potential causes of a hazard (cf. Table 2). Other potential failure modes are
not relevant for this scenario. As input from the Security Pattern Engineering
phase, we get the information that the Security Gateway adds a small latency
to the communication between the CI and the BMS. This small delay can cause
a minor amount of extra charging in the battery which is not a source of hazard590
and need no further investigation in the safety and security co-engineering loop.
24
Figure 7: Architecture after the first iteration of safety and security co-engineering
Table 2: HAZOP Guideword analysis of the architecture
Guideword Possible causes Possible consequences
Commission - -
Omission Gateway blocks message to
stop charging - Message gets
corrupted
Charging Interface keeps pro-
viding energy to battery
Early - -
Late Additional processing time
slows down reaction time of
components
Late disconnection of battery
Value High - -
Value Low - -
25
From the input received from the previous phase, we also discovered that
the safety functions on the CI will not suffice in the case of a hacker attack.
This need a further investigation by performing a Safety and Security Analysis.
Safety and Security Co-Analysis. The two-stage SAHARA method then com-595
bines the outcome of the security analysis with the outcomes of the safety anal-
ysis. The SAHARA method applies a key concept of the HARA approach, the
definition of ASILs, to the STRIDE analysis outcomes. Security threats that
might lead to a violation of safety goals can be handed over to HARA for fur-
ther safety analysis. This helps to improve completeness of safety analysis in600
terms of the safety requirement of analysis of ’foreseeable misuse’, in this case
hazardous events initiated due to security attacks. For the battery system it
can be seen that security hazard are aiming a overloading of the battery because
the CI keeps providing energy to the battery.
Harmonize. To tackle this issue a CI fail-safe device connected to the Monitor605
channel was integrated (cf. Figure 7). Of course, one obvious drawback in
this solution is the extra cost incurred due to extra hardware and installation.
The changes in the architecture neither create new vulnerabilities nor jeopardize
the current mechanisms already in place. Furthermore, additional requirements
can be added to the Security Gateway in the security concept, specifying that610
firewall rules shall not block critical messages in charging process, which can be
implemented and tested in the development phase.
Trade-Off. After finalization of the safety and security pattern engineering ac-
tivities, the design can be reviewed to check whether all applied patterns can
co-exist and whether there is no unwanted influence. While there is a direct615
review of the design with the applied patterns after each iteration, a final check
can ensure the soundness of the design. In [33] we presented a quantitative
methodology for security risk assessment by combining FMVEA and SAHARA
methods with the FAIR method. This enables the analysis of security and
failure event chains, as well as a coordinated risk management for safety and620
26
security features. In this case, it was decided to add the Security Gateway as an
additional component in the system, to not only ensure that safety pattern and
the security pattern do not interfere with each other, but also to support the
maintainability of the security solution. Updates to the gateway do not impact
the safety pattern directly.625
Argumentation. During the task argumentation the safety and security concept
is finally available and all argument fragments through the overall workflow
are consolidated: GSN argumentation fragments of the chosen patterns (e.g.
security pattern for firewall in Figure A.11), co-analysis results, and evidences
of the elaborated safety and security measures from harmonization and/or trade-630
off. The joint assurance case contains the combined safety and security case.
4.2.4. Modeling of the System
For the item definition of the system we used the block definition diagram
(bdd) of SysML. The blocks, their hierarchy and multiplicities (e.g. exactly one
module consists of at least one cell) are defined based on the use case description635
and requirements (cf. Figure 8 [Top]). Furthermore, all input and output ports
are defined as known so far. This item definition is compliant to ISO 26262 and
subject to further safety and security analyses.
4.2.5. Modeling Patterns
In a similar way, patterns are modeled. Patterns may contain UML classes640
(or blocks in SysML, as equivalent) and their relationships (cf. Figure 8 [Bot-
tom]). The diagram is saved as a pattern and stored in a separate XML file
format and stored in the pattern repository. A specific save dialog offers sev-
eral options (e.g. specification of name, file-name, and category). The classes
of the patterns may be replaced with classes from your system model during645
the integration later on, which needs to be enabled by ticking the boxes in the
corresponding columns (create/merge/instance/type). To give an example, the
merge option replaces an existing model element with an element defined in
27
Figure 8: [Top]: Item Definition in SysML |[Bottom]: Creation of Safety Pattern
[Tool:Enterprise Architect]
28
the pattern. This is especially useful for larger patterns, and ensures seamless
integration of the pattern with an existing model.650
4.2.6. Pattern Instantiation
The pattern may then be applied to the system model by drag and drop of
the pattern to the diagram by a following dialog window, where it is possible
to assign existing elements to the pattern (cf. Figure 8 Bottom). In the exam-
ple the Pattern “Primary channel” is mapped to the BMS “Process” and the655
Pattern “HomogenousRedundancyStructure” is mapped to the BMS. Based on
the mapping the tool updates the bdd with the missing classes from the chosen
pattern and the pattern import is completed.
4.2.7. Interaction with Analysis Tool
Threat Modeling is a wide spread security analysis, which is also one of660
the contributions for co-analysis techniques like SAHARA or FMVEA. The
main tool for Threat Modeling has been a plug-in for MS Visio, which only
provides a graphical modeling support. The tool from AIT in development
called “ThreatGet” integrates Threat Modeling into Enterprise Architect. With
the integration into EA the threat modeling is based on a SysML model and665
resulting threats can be integrated into the workflow and guarantee traceability.
4.3. Lessons Learned
The definition of patterns in the EA tool is done via simple UML class
diagrams and works for SysML blocks as well. The pattern are saved in separate
files in a software versioning and revision control system, which allowed to built670
easily a “library of patterns”. Furthermore, it is easy to apply the patterns
to the system model via drag and drop. The pattern mechanism of the EA
tool seems to work at this stage for bdd diagrams only, which means that the
pattern “just reminds you to add needed blocks” and the engineer has to connect
them as needed according to the specific context. The concrete interconnections675
between blocks, normally realized via interfaces and ports, are out of scope of
the EA patterns. This is due to the fact that at this point in time the exact
29
definition of ports and interfaces, etc. are unknown. The described approach
using EA limits the application of patterns to early development phases.
4.4. Industry Relevance680
Currently vehicle chargers can be mainly classified into: AC charging that
uses residential power outlet, DC fast charging (DCFC) that charges a vehicle
by DC in much shorter time, and inductive charging that eliminate the use of ca-
bles. All of them require certain message exchange between the charging station
and the vehicle during the charging process to regulate the current provided to685
the vehicle. SAE recommendations are often used in the industry to implement
such communications on top of the physical and data link layer. For exam-
ple, SAE J2847/2 “Communication between plug-in vehicles and off-board DC
chargers” [34] defines message format for DC charging. These messages might be
manipulated to sabotage the charging process that leads to battery explosion.690
Therefore, in SAE J2931/7 “Security for plug-in electric vehicle communica-
tions” [35] a set of security requirements are specified for different stakeholders
involved in the system. On the other hand, standards such as ISO 17409:2015
“Preview Electrically propelled road vehicles - Connection to an external elec-
tric power supply - Safety requirements” [36] specifies the safety requirements.695
The safety and security pattern described here has been instantiated in certain
degree in actual vehicles, which use a gateway to avoid direct data connection to
charging station and relays controlled by BMS to avoid overcharging. Therefore,
safety and security patterns can be an repeatable and efficient way to address
and enforce safety and security requirements from related standards in system700
development based on industry best practices.
5. Discussion and Conclusion
This paper focused on the selection, combination, and application of safety
and security patterns for automotive system engineering. The introduction of
the Combined Pattern-based Engineering Workflow provides a systematic and705
30
integrated way of safety- and security-related pattern engineering. It provides
comprehensive guidance and packaged knowledge with respect to the integra-
tion, as well as auxiliary existing work products, such as the (initial) results
of safety and security analyses and argumentation fragments. The availability
of recurring process steps based on automotive industry standards results in710
faster and cheaper product development while fulfilling the need for intangi-
ble product properties, namely safety and security. The Safety and Security
Co-Engineering Loops as well as the correlated guidance provided by our aug-
mented pattern descriptions help to align the required activities systematically
and foster a tight integration of safety- and security-related process steps. For715
instance, this means if a safety (architectural) pattern will be selected to address
a specific safety requirement, additional information and guidance with respect
to correlated core aspect from a security point of view are provided. A security
pattern, in turn, can have a safety impact, which is again explicitly specified.
With the presented approach, the decision which pattern fits best for a720
specific system can be done more systematically (particularly by non-expert en-
gineers) and taking into account the problem to be addressed and the context
of the system. In general, safety and security engineering are very closely re-
lated disciplines and their synergy can be fostered when their similarities are
recognized and adequate interactions are established correctly.725
To demonstrate the benefits of the presented approach an automotive case
study demonstrated the practical realization of our approach: Architecture of
an automotive battery system was described in a semi-formal way, including
identification of its main components, physical interconnections, and flows of in-
formation. The use case has been reduced in complexity for illustration purposes730
and it highlights the benefits of applying the Pattern Engineering Workflow for
the concept phase development.
With the presented approach, we aimed to benefit from the typical strong
points of patterns to overcome the lack of general security knowledge as well as
organizational weak points (i.e. no integrated safety-security teams, distributed735
or lacking security knowledge etc) that are prevalent in the automotive domain.
31
It is a promising approach that should help accelerating the application of ad-
equate safety and security co-engineering in industry. In particular, we believe
the type of pattern we introduced constitute a way to remediate the lack of
security knowledge and facilitate easier and more informed integration of these740
two separate yet interfering disciplines. Additionally, initial positive experiences
were shown, which were gained by a tool supported model-based systems en-
gineering application, where patterns were created and applied for a specific
automotive use case scenario.
Acknowledgment745
Dedicated to our co-author late Christian Kreiner, who was impressive for
many reasons and has been a wonderful teacher, co-worker, leader and friend.
You have been everything one could look for in a good mentor, the true Master
Yoda, and made working with you an exciting, inspiring and memorable expe-
rience. We will always be grateful to you for your support and kindness. May750
the force still be with you.
Research leading to these results has received funding from the EU ECSEL
Joint Undertaking under grant agreement no. 692474 (project AMASS), EU
ECSEL JU project SCOTT (no. 737422), EU Horizon 2020 research and innova-
tion programme under grant agreement no. 732242 (project DEIS), and from the755
COMET K2 - Competence Centres for Excellent Technologies Programme of the
Austrian Federal Ministry for Transport, Innovation and Technology (bmvit),
the Austrian Federal Ministry of Science, Research and Economy (bmwfw), the
Austrian Research Promotion Agency (FFG), the Province of Styria, and the
Styrian Business Promotion Agency (SFG), the German Federal Ministry of760
Education and Research (BMBF), grant CrESt, 01IS16043.
32
List of Abbreviation
Table 3: List of Abbreviation
Abbrev. Definition Abbrev. Definition
AC Alternating Current HARA Hazard Analysis and Risk Management
ASIL Automotive Safety Integrity Level HAZOP HAZard and OPerability Study
BMS Battery Management System HV High Voltage
C Controlability ID Identifier
CAN Controller Area Network ISO International Organization for Standard-
ization
CI Charging Interface IT Information Technology
CPS Cyber-Physical System MBSE Model-Based Systems Engineering
DCFC Direct Current Fast Charging MS MicroSoft
DFD Data Flow Diagram S Severity
E Exposure SAE Society of Automotive Engineers
E/E Electric and/or Electronic SAHARA Security Aware Hazard Analysis and Risk
Assessment
EA Enterprise Architect STRIDE Spoofing, Tampering, Repudiation, Infor-
mation disclosure, Denial of Service, Ele-
vation
ECU Electronic Control Unit SysML System Modelling Language
FDIS Final Draft International Standard TARA Threat Analysis and Risk Assessment
FMVEA Failure Mode and Vulnerability Eect Anal-
ysis
UML Unified Modelling Language
GSN Goal Structuring Notation XML Extensible Markup Language
References
[1] A. Joshi, M. P. Heimdahl, S. P. Miller, M. W. Whalen, Model-Based Safety
Analysis, Tech. Rep. CR-2006-213953, NASA (2006).765
[2] B. Kaiser, V. Klaas, S. Schulz, C. Herbst, P. Lascych, Integrating system
modelling with safety activities, in: SAFECOMP’10 Proceedings of the
29th international conference on Computer safety, reliability, and security,
Springer, 2010, pp. 452–465.
URL http://link.springer.com/chapter/10.1007/770
978-3-642-15651-9_33
[3] T. Amorim, H. Martin, Z. Ma, C. Schmittner, D. Schneider, G. Macher,
B. Winkler, M. Krammer, C. Kreiner, Systematic pattern approach for
safety and security co-engineering in the automotive domain, in: Interna-
tional Conference on Computer Safety, Reliability, and Security, Springer,775
2017, pp. 329–342. doi:10.1007/978-3-319-66266-4_22.
33
[4] ISO, ISO 26262 Road vehicles – Functional safety (2011).
[5] SAE, SAE J3061 Cybersecurity Guidebook for Cyber-Physical Vehicle Sys-
tems (2016).
[6] C. Schmittner, G. Griessnig, Z. Ma, Status of the development of780
iso/sae 21434, in: European Conference on Software Process Improvement,
Springer, 2018, pp. 504–513.
[7] G. Macher, E. Armengaud, C. Kreiner, E. Brenner, C. Schmittner, Z. Ma,
H. Martin, M. Krammer, Integration of security in the development life-
cycle of dependable automotive cps, in: Handbook of Research for Cyber-785
Physical Systems Ubiquity, IGI Global, 2017.
[8] C. Schmittner, Z. Ma, E. Schoitsch, T. Gruber, A case study of fmvea and
chassis as safety and security co-analysis method for automotive cyber-
physical systems, in: Proceedings of the 1st ACM Workshop on Cyber-
Physical System Security, CPSS ’15, ACM, New York, NY, USA, 2015, pp.790
69–80. doi:10.1145/2732198.2732204.
[9] G. Macher, H. Sporer, R. Berlach, E. Armengaud, C. Kreiner, Sahara: A
security-aware hazard and risk analysis method, in: 2015 Design, Automa-
tion Test in Europe Conference Exhibition (DATE), 2015, pp. 621–624.
doi:10.7873/DATE.2015.0622.795
[10] C. Schmittner, Z. Ma, T. Gruber, E. Schoitsch, Safety and security co-
engineering of connected, intelligent, and automated vehicles, ERCIM News
109 (2017) 23–24.
[11] T. Gruber, C. Schmittner, M. Matschnig, B. Fischer, Co-engineering-in-
the-loop, Computer Safety, Reliability, and Security (2018) 151.800
[12] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King,
S. Angel, A pattern language (1977).
34
[13] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of
Reusable Object-oriented Software, Addison-Wesley Longman Publishing
Co., Inc., Boston, MA, USA, 1995.805
[14] A. Armoush, Design patterns for safety-critical embedded systems., Ph.D.
thesis, RWTH Aachen University (2010).
[15] C. Preschern, N. Kajtazovic, C. Kreiner, Building a safety architecture pat-
tern system, in: Proceedings of the 18th European Conference on Pattern
Languages of Program, EuroPLoP ’13, ACM, New York, NY, USA, 2015,810
pp. 17:1–17:55. doi:10.1145/2739011.2739028.
URL http://doi.acm.org/10.1145/2739011.2739028
[16] B. P. Douglass, Real-Time Design Patterns: Robust Scalable Architecture
for Real-Time Systems, Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 2002.815
[17] B. P. Douglass, Design Patterns for Embedded Systems in C: An Embedded
Software Engineering Toolkit, 1st Edition, Newnes, Newton, MA, USA,
2010.
[18] L. L. Pullum, Software Fault Tolerance Techniques and Implementation,
Artech House, Inc., Norwood, MA, USA, 2001.820
[19] M. Schumacher, Security engineering with patterns: origins, theoretical
models, and new applications, Vol. 2754, Springer Science & Business Me-
dia, 2003.
[20] N. A. Delessy, E. B. Fernandez, A pattern-driven security process for soa
applications, in: 2008 Third International Conference on Availability, Re-825
liability and Security, 2008, pp. 416–421. doi:10.1109/ARES.2008.89.
[21] N. E. Petroulakis, G. Spanoudakis, I. G. Askoxylakis, A. Miaoudakis,
A. Traganitis, A pattern-based approach for designing reliable cyber-
physical systems, in: 2015 IEEE Global Communications Conference
(GLOBECOM), 2015, pp. 1–6. doi:10.1109/GLOCOM.2015.7417794.830
35
[22] J. A. Estefan, et al., Survey of model-based systems engineering (mbse)
methodologies, Incose MBSE Focus Group 25 (8) (2007) 1–12.
[23] OMG Systems Modeling Language (OMG SysML) (2012),
http://www.omg.org/spec/SysML/1.3/ (Jun. 2012).
[24] S. Friedenthal, A. Moore, R. Steiner, A practical guide to SysML: The835
systems modeling language, Morgan Kaufmann, 2014.
[25] G. Biggs, T. Sakamoto, T. Kotoku, A profile and tool for modelling safety
information with design information in SysML, Software & Systems Mod-
eling 15 (1) (2016) 147–178. doi:10.1007/s10270-014-0400-x.
URL http://link.springer.com/10.1007/s10270-014-0400-x840
[26] Muhammad Sabir Idrees, Yves Roudier, Ludovic Apvrille, A Framework
Towards the Efficient Identification and Modeling of Security Require-
ments, 2010.
[27] C. Preschern, N. Kajtazovic, C. Kreiner, Security analysis of safety pat-
terns, in: Proceedings of the 20th Conference on Pattern Languages of845
Programs, The Hillside Group, 2013, p. 12.
[28] A. Karahasanovic, P. Kleberger, M. Almgren, Adapting threat modeling
methods for the automotive industry, in: Proceedings of the 15th ESCAR
Conference, 2017, pp. 1–10.
[29] Z. Ma, C. Schmittner, Threat modeling for automotive security analysis,850
Advanced Science and Technology Letters 139 (2016) 333–339.
[30] M. Hamad, M. Nolte, V. Prevelakis, Towards comprehensive threat mod-
eling for vehicles, in: the 1st Workshop on Security and Dependability of
Critical Embedded Real-Time Systems, 2016, p. 31.
[31] Sparx Services CE – Cyber Security Modeling – Security by design, [Online;855
accessed 5. Jul. 2019] (Jul 2019).
URL https://cybersecurity.sparxservices.eu
36
[32] A. Shostack, Threat Modeling: Designing for Security, Wiley, 2014.
URL https://books.google.de/books?id=asPDAgAAQBAJ
[33] J. Dobaj, C. Schmittner, M. Krisper, G. Macher, Towards Integrated Quan-860
titative Security and Safety Risk Assessment, in: Computer Safety, Relia-
bility and Security - SAFECOMP 2019 Workshops - ASSURE, DECSoS,
SASSUR, STRIVE, and WAISE , Vol. LNCS of Lecture Notes in Computer
Science, Springer International Publishing AG, 2019.
[34] SAE, SAE J2847/2 Communication between plug-in vehicles and off-board865
DC chargers (2015).
[35] SAE, SAE J2931/7 Security for Plug-In Electric Vehicle Communications
(2018).
[36] ISO, ISO 17409 Electrically propelled road vehicles – Connection to an
external electric power supply – Safety requirements (2015).870
Appendix A. Pattern Examples
This section shows some pattern examples of our approach to describe pattern:
•pattern template see Figure A.9;
•safety pattern example see Figure A.10;
•security pattern example see Figure A.11.875
37
Figure A.9: Pattern Template
38
Figure A.10: Safety Pattern Example
39
Figure A.11: Security Pattern Example
40
