Conference PaperPDF Available

Towards (Semi-)Automated Synthesis of Runtime Safety Models: A Safety-Oriented Design Approach for Service Architectures of Cooperative Autonomous Systems

Authors:

Abstract and Figures

Future automotive systems will exhibit ever-higher grades of automation up to the point of autonomy. The full potential in automation can only be unlocked when combining it with the capability of cooperation, leading to the vision of comprehensively networked cooperative autonomous systems (CAS). To enable a safe CAS cooperation at runtime, we introduced the ConSert approach in previous work, which allows fully automated safety interface compatibility checks in the field based on runtime safety models. However, a systematic engineering approach for synthesizing these runtime safety models based on design time architecture and safety models does not exist to date. As all safety-engineering activities require the functional description of a system as input, we describe in this paper, how a top-down service-based design approach can look like for CAS, preparing an effective safety analysis and formulation of black-box behavioral deviation bounds in shape of safety guarantees and demands. Thereby, we point out challenges, which especially occur due to the complexity introduced by the distributed development of CAS. These challenges are exemplified for the traffic light assistant system, an example CAS from the automotive domain.
Content may be subject to copyright.
Towards (Semi-)Automated Synthesis of Runtime
Safety Models: A Safety-Oriented Design Approach
for Service Architectures of Cooperative
Autonomous Systems
Jan Reich
()
and Daniel Schneider
Fraunhofer IESE, Kaiserslautern, Germany
{jan.reich,daniel.schneider}@iese.fraunhofer.de
Abstract. Future automotive systems will exhibit ever-higher grades of auto‐
mation up to the point of autonomy. The full potential in automation can only be
unlocked when combining it with the capability of cooperation, leading to the
vision of comprehensively networked cooperative autonomous systems (CAS).
To enable a safe CAS co operation at runtime, we introduc ed the ConSert approach
in previous work, which allows fully automated safety interface compatibility
checks in the field based on runtime safety models. However, a systematic engi‐
neering approach for synthesizing these runtime safety models based on design
time architecture and safety models does not exist to date. As all safety-engi‐
neering activities require the functional description of a system as input, we
describe in this paper, how a top-down service-based design approach can look
like for CAS, preparing an effective safety analysis and formulation of black-box
behavioral deviation bounds in shape of safety guarantees and demands. Thereby,
we point out challenges, which especially occur due to the complexity introduced
by the distributed development of CAS. These challenges are exemplified for the
traffic light assistant system, an example CAS from the automotive domain.
Keywords: Safety interface synthesis · ConSerts · Service architecture
1 Introduction
Cooperative autonomous transportation systems (CAS) are the next evolution step of
automotive systems realizing innovative applications, which are subsumed under the
term Smart Mobility [1]. They aim at advancing the human driving experience with
significant improvements to energy consumption, driving comfort or vehicle safety.
However, these benefits can only be unlocked by extending the perception and action
horizon of traditional systems through cooperation, i.e. both knowledge and capabilities
of a system must be made accessible to its vicinity over wireless communication so that
other systems can leverage from these capabilities.
The development of CAS is a complex endeavor as cooperative applications are
executed on a set of different systems developed by different manufacturers. For CAS it
is therefore not possible to completely predict the system structure or behavior already at
© Springer Nature Switzerland AG 2018
B. Gallina et al. (Eds.): SAFECOMP 2018 Workshops, LNCS 11094, pp. 139–150, 2018.
https://doi.org/10.1007/978-3-319-99229-7_13
design time, because environmental conditions such as the weather as well as the capabil‐
ities of potential collaboration partners can only be resolved in a concrete runtime situa‐
tion – when all of these collaboration partners as well as other dynamic context properties
of the environment are known. Consequently, mechanisms need to be developed that
realize such dynamic context evaluation and system of system integration based on the
evaluation results.
Many CAS especially in the automotive sector are safety-critical. Therefore, the
assurance of system safety is an obligatory activity before a CAS can be introduced to the
market. Due to the fact that safety is a system property and the runtime operational
context is at most incompletely known, safety can only be demonstrated for the CAS at
runtime, but not through the mere safety certification for each constituent system at design
time alone. Consequently, parts of the safety assurance need to be shifted into runtime.
One corresponding means are conditional safety certificates (ConSerts) [2] that are a
model-based runtime representation of safety guarantees and demands (and mapping
functions in between) associated to black-box functional interfaces of a system or to other
properties of the relevant environmental context (runtime evidences). By equipping each
constituent system with models about its provided and required functional behavior as
well as associated safety guarantees and demands, interface compatibility checks can be
automatically executed. Dynamic composition hierarchies are formed and at the root
nodes of the hierarchies, the top-level safety guarantees for the collaboration at hand can
be determined based on the safety guarantees and demands along the branches of the
hierarchy. Based on this evaluation, it can be decided, whether a collaboration is safe to
run and which constraints or parameterization might be necessary. As safety guarantees
and demands specify maximum allowed bounds on externally visible deviations relative
to the intended provided or required behavior, a precise specification of the nominal func‐
tional behavior is indispensable. Service-oriented approaches are a suitable means to
describe black-box behavior interfaces in terms of services.
Even though the ConSerts approach enables the model-based integration of safety
interfaces at runtime, the required models and mechanisms have to be synthesized
manually already at design time, as the demonstration of sufficient safety with minimum
cost needs a certain creativity that machines do not have to date. Moreover, the goal is
to shift only those safety decisions to runtime, where design time knowledge is insuffi‐
cient. Consequently, runtime safety models such as ConSerts should be synthesized out
of well-understood traditional safety engineering activities carried out at design time
such as fault tree analysis, hazard analysis and safety concept creation.
In this paper, we describe a top-down service-based design approach for CAS, which
enables effective safety analysis and formulation of black-box behavioral deviation
bounds in shape of safety guarantees and demands. Thereby, we point out challenges,
which especially occur due to the complexity introduced by the distributed development
of CAS. These challenges are exemplified by means of a traffic light assistant system,
an example CAS from the automotive domain.
140 J. Reich and D. Schneider
2 Top-Down Design of Cooperative Autonomous Systems
This section describes a top-down approach for the functional and architectural design
of CAS. In order to make the described concepts and challenges in this paper more
tangible, a traffic light assistant system (TLA) introduced in [3] shall be used as an
example. The TLA’s goal is to improve the energy consumption of a vehicle by auto‐
matically adjusting the vehicle speed in a way that green traffic light waves can be driven,
thus minimizing energy loss due to unnecessary braking at red lights. As the perception
capabilities of both driver and vehicle-internal sensors, such as radar or camera, are
limited regarding their range, the idea of TLA is to make external knowledge from
intersection control systems and/or other vehicles accessible to the ego vehicle.
Connectivity and cooperation are key enablers for intelligent new CAS applications
such as the TLA, because intelligent or autonomous behavioral decisions yielding the
desired benefits can only be taken based on comprehensive knowledge about the
system’s environment. This access of knowledge does not only enable intelligent appli‐
cations, but it does so in a very cost-effective manner, because also systems with limited
local sensing capabilities can benefit from rich context knowledge through connectivity.
The remainder of this section will sequentially guide through a top-down design
approach for CAS (see Fig. 1) covering the application design of the CAS, the subse‐
quent allocation of functionality to systems and components as well as the implications
of the allocation on both vertical and horizontal development interfaces.
Fig. 1. Top-down approach for cooperative autonomous system development
2.1 Service-Oriented CAS Application Refinement
A cooperative application such as the TLA can only be realized through an interplay of
several connected systems, which may be developed in isolation by different companies.
Moreover, for the execution of such an application, there are several conceivable system
Towards (Semi-)Automated Synthesis of Runtime Safety Models 141
topologies incorporating variations in the provided services of each system and their
quality. Therefore, the conceptualization and design of the application itself needs to
abstract from concrete systems and thus happen on the functional level, which enables
a decoupling of the application’s specification from its concrete realization.
More specifically, this means that the derivation of interfaces during the functional
refinement of the CAS application into CAS sub-functions is a critical factor for the
probability of a successful cooperation at runtime. Depending on its planned capabilities,
each constituent system can then implement one or more CAS sub functions (i.e.
provides a service) with precisely defined interfaces (e.g. adhering to a standardized
service type). If every system manufacturer adheres to the application specification by
implementing a subset of the CAS functionality, a successful cooperation can be guar‐
anteed at runtime under the condition that the whole CAS functionality is covered by
the systems to be integrated. This means that service types, which represent sub functions
of the application, are established as development interface for the system manufac‐
turers. Note that the CAS application abstraction enables successful runtime cooperation
without the necessity for case-by-case coordination between system manufacturer
companies, because this coordination is replaced by precisely defined interface speci‐
fications by means of services during the CAS application design phase.
The functional application design of the TLA is shown in Fig. 2. The TLA’s provided
service to the ego vehicle driver is the automated control of longitudinal movement to
efficiently cross intersections. This is the starting point for the hierarchical service
refinement, where the service type classification from [4] was used during the service
identification. A fundamental difference to conventional actuator-based design methods
is that the interfaces between sub functions are not defined and structured according to
the intended data flow direction (rounded gray arrow), but in terms of service provision
direction [5] (patterned arrows). This enables the modular hierarchization from services
with high context knowledge (Plan and control ego vehicle de-/acceleration) to services
with lower context knowledge (e.g., Determine safe ego vehicle speed profile or Control
Fig. 2. Functional application design of the “Traffic Light Assistant”
142 J. Reich and D. Schneider
vehicle speed). While the direction of service provision for sensing services (left in
Fig. 2) matches the dataflow direction, this is different for the actuation branch (right in
Fig. 2), where the provided service of Control vehicle speed abstracts from the actual
details of how the speed is controlled.
Synthesizing functional interfaces according to service provision has the benefit that
the required context knowledge for a function is decreasing in line with the concreteness
of the function (i.e. going further down in the hierarchy), which is not the case, if func‐
tions are structured according to dataflow (see Fig. 3). For instance, the Brake ego vehicle
function does not need to know about the context in which braking is required, while
Plan and control ego vehicle de-/acceleration needs full context for properly fulfilling
its responsibility, but does not care of how required information is gathered and concrete
vehicle control such as braking is performed. This scheme is analog to the modular-
hierarchical allocation of safety responsibilities that is used in conjunction with the
ConSerts approach. Each constituent system in the hierarchy has the safety scope of its
provided service, including everything below in the hierarchy – i.e. all services rendered
by lower level systems that are required for rendering the provided service. For appli‐
cation services, this means that they have the safety scope of the overall application such
as, for instance, the TLA (cf. [6] for further information).
Fig. 3. Hierarchical context knowledge reduction during service decomposition
Another major difference between the dataflow-oriented and the service-oriented
description of functions is the perspective, from which the input-output relationship of
a function is described. The difference is depicted with arrows at the Planning Service
in Fig. 3. In the dataflow-oriented case, a function specifies the intended relation between
data input and data output. This requires, however, to expose information about the
function’s realization (i.e. which concrete inputs are needed to produce the output),
which detriments modularity and in consequence prevents a strict black-box description
Towards (Semi-)Automated Synthesis of Runtime Safety Models 143
of provided functionality. In order to preserve the desired modularity when specifying
behavior, it shall be described from the perspective of the service consumer [7]. This
means that the service consumer (typically another system or component) can only
perceive the external visible behavior through a service interface. For instance, the
Control Vehicle Speed function in Fig. 2 provides the service Realize a vehicle speed
set point within x sec after request. This service description does not expose details about
how this realization is performed (i.e., by braking or accelerating), as from the service
consumer perspective, the service’s behavior can only be perceived by the external
visible state, which is a change in the vehicle’s speed over time after the consumer
triggered the service execution.
Thus, in summary, the key trait in using a service concept is that the external visible
behavior is described independently from the functional realization rendering it. Due to
these characteristics, the service-oriented function refinement has major benefits when
it comes to the synthesis and integration of system interfaces across multiple system and
company boundaries. In addition, the ability to express black-box service interfaces
abstracting from lower-level functions paves the way for a proper identification and
description of safety-critical behavioral deviations referring to the externally visible
behavior only.
2.2 CAS System Interface Derivation
After the CAS application has been planned in terms of a functional service decompo‐
sition, it has to be distributed to concrete systems realizing it. A hypothetical CAS func‐
tion allocation for the TLA to a set of systems and components is shown in Fig. 4.
Fig. 4. Establishment of system service interfaces through CAS function allocation
The allocation shows three systems that will execute the cooperative TLA behavior
at runtime, the Ego Vehicle System, the Intersection Control System and the Front
Vehicle System, which represents a car driving in front of the ego vehicle within the TLA
scenario emitting its own position to the ego vehicle via Wi-Fi. Within the Ego Vehicle
144 J. Reich and D. Schneider
System, functionality has been further allocated to several components being provided
to the ego vehicle OEM by Tier 1 and 2 suppliers.
An important observation is that there exist many different allocation possibilities
for the same application. For instance, the function Determine safe ego vehicle speed
profile along with their required service Determine front obstacles could also be
executed by an off-the-shelf collision avoidance system, if the ego vehicle was equipped
with such a system. The implication would be that the manufacturer of the TLA compo‐
nent could rely on the ego vehicle platform to avoid rear-end collisions leading to a
lower development cost. However, this would lead to a lower probability for a successful
cooperation, because the TLA component needs to make an additional assumption that
needs to be fulfilled by the integration context (i.e. the ego vehicle). Thus, the analysis
of multiple allocation variants is of outmost importance to properly resolve the trade-
off between cost and availability.
In principle, service interfaces between systems are automatically determined by the
mere function allocation to a concrete system and component structure. However, the
required level of detail for the development interface contracts varies significantly
depending on the relation type of connected systems (CAS constituent system, Tier 1
component, Tier 2 component) and the time when the integration has to be performed
(design time vs. runtime). In order to effectively support automated interface synthesis
and integration of both functional and safety interfaces, it is important to understand the
properties and differences of the interface types.
In general, interface synthesis describes the task, where an interface description is
generated that contains sufficient information for the interface consumer to independ‐
ently perform the intended realization without further coordination with the interface
provider. On the other hand, interface integration describes the activity, where one or
more concrete realizations of an interface are checked against the interface with respect
to consistency and assumption validity in both directions.
For the TLA, we identified five different interface types that can be distinguished
with respect to their required properties and challenges for synthesis and integration
(numbers in Fig. 4).
1. Company-Internal: With interfaces that are generated and realized by the same
company, the main challenge lies in making the interface synthesis and integration
activities as efficient as possible. Considering for instance that the functions Deter‐
mine safe ego vehicle speed profile and Determine energy-optimal ego vehicle speed
profile are developed by different business units of the Traffic Light Assistant System
Provider. These might use different tools and techniques for the function realization,
but there are no needs for intellectual property protection within a company. Thus,
for an efficient interface synthesis and integration with the high-level control func‐
tion Plan and control ego vehicle de-/acceleration, fully detailed white-box models
can serve as a basis.
2. Tier 1 - OEM: A fundamental property of this interface relationship is that the OEM
generates an interface specification that enables the supplier to deliver a component
fitting into the OEM system. This poses serious challenges for the safety mechanisms
that have to be implemented by the supplier, as they are dependent on the OEM
system context. Nowadays, the safety interfaces between OEM and Tier 1 are often
Towards (Semi-)Automated Synthesis of Runtime Safety Models 145
comprised only of a set of textual safety requirements that shall be fulfilled by the
supplied component. However, the resulting requirements do often not contain
sufficient information on the integration context to allow an isolated component
development. This leads in the best case to correct assumptions about the integration
context on supplier side and in the worst case to further information gathering iter‐
ations yielding additional effort. After a component has been realized, the OEM
needs to check, whether the integrated component satisfies the generated (safety)
interface. This includes on the one hand checking validity of assumptions and on the
other hand performing system tests, which is problematic especially in early devel‐
opment phases.
In summary, the key challenge of this interface type is to first generate a precise
safety development interface containing sufficient contextual information to avoid
unnecessary interactions. For the subsequent integration phase, it is deemed desir‐
able to have (semi-)automated integration methods that can check the component’s
realization against the interface specification. In this step, model-based integration
shall ideally be used to detect interface compatibility flaws, which increases confi‐
dence in the supplied component before system safety tests can be performed.
3. Tier 1 – OEM – Tier 2: This relation type introduces an interface from a supplier
1 over OEM to a supplier 2. The difference to the Type 2 interface is that the OEM
has to generate and maintain two interfaces that are horizontally dependent on each
other, because the two components provide a single OEM-level function together.
During integration, the integrator has to check the interoperability of different
supplied components given the context of the OEM system. This includes checking
the validity of assumptions posed by all supplied components together and checking
whether the goals of the OEM-level functions with respect to performance, timing
and safety are satisfied.
4. Tier 1.1 – OEM – Tier 1.2 – Tier 2: This relation type extends Type 3 interfaces
with another lower-level interface, where the ADAS Basis System Provider acts as
both interface implementer and generator. The complexity arising from this relation
is that the interface realization of the OEM interface depends on the interface real‐
ization of the Environment Perception System Provider, i.e. changes propagate over
multiple vertical integration interfaces demanding for proper traceability as first-
class objective to minimize efforts for change impact analyses.
5. Vendor 1 – Vendor 2: The interface between constituent systems of a CAS such as
vehicles from different vendors and the Intersection Control System share the prop‐
erty that these systems are developed in complete isolation based on service inter‐
faces derived at the CAS application refinement. Thus, their interoperability can be
checked only as soon as they are about to form a CAS at runtime. Since, no humans
are involved at runtime; the integration must be carried out fully automated in turn
demanding machine-processable interface models. A major challenge for deriving
these machine-processable interface models is the required level of precision and
unambiguity in describing both intended functionality (i.e., the service) and its devi‐
ations (i.e. the safety guarantees/demands) from a black-box perspective.
Note that the identified interface types 1–4 are not new as these are classical interface
types that also emerge during the development of closed systems. Nevertheless, they
146 J. Reich and D. Schneider
have been added to emphasize the fact that CAS functionality has to be built on top of
existing systems, which are developed according to traditional methods and organiza‐
tional structures. Therefore, the additional engineering activities required for the devel‐
opment and safety assurance of CAS functionality (CAS application design, runtime
interface synthesis and integration in Fig. 1) have to be harmonized with the traditional
ones by defining clear process and artifact interfaces.
During the isolated development of constituent systems such as a vehicle, this means
in particular a continuous model-based synthesis and integration of design time models
starting at the CAS application design phase and ending in an integrated design time
model of the whole constituent system. Such an integrated design time model consists,
for instance, of detailed architecture models, hazard models, failure propagation models
and safety concept models. For this context, a conceptual framework (DDI – Digital
Dependability Identities) for the synthesis and exchange of dependability-related design
time and runtime models is currently developed in the European DEIS project [8]. In
order to make a constituent system ready for runtime integration, the integrated design
time models need to be transformed into black-box runtime representations of provided
and required services as well as their safety guarantees and demands in shape of
ConSerts. However, as these transformations will be still carried out at design time,
adequate tool support will be necessary to enable engineers to synthesize correct runtime
interfaces (Type 5) in an effective and efficient way.
3 Related Work
There have been various evaluations and attempts for the application of service-oriented
design approaches (SOA) in a cooperative system context.
As part of the EMC
2
project, a state-of-the-art-analysis for the general applicability
of SOA in the embedded system domain has been performed [9]. The analysis concludes
that a trend towards such architectures can be found but an accepted approach in the
automotive context is not presented in the report.
The distribution of sensor fusion across different cars in a cooperative adaptive cruise
control scenario (CACC) implemented with SOA has been presented in [10]. One
fundamental assumption in this case was that only the environmental situation around
the cooperation changed, while the internal systems of the cars stayed static over coop‐
eration time, which is typically not the case for CAS as system topologies can explicitly
change.
Wagner et al. proposed a SOA-based middleware solution as well as a development
process guiding the creation of service architectures of distributed driver assistance
systems in [11]. The approach is derived from IBM’s “Service-Oriented Modeling and
Architecture” methodology and is called Service-Oriented Driver Assistance (SODA).
For the development and documentation of service models, they used the Service
Oriented Modeling Language (SoaML). While the SODA approach considers the use
of SOA for middleware decoupling, the approach presented in this paper focuses explic‐
itly on the application level, i.e. the decoupling of functionality on the CAS level.
Towards (Semi-)Automated Synthesis of Runtime Safety Models 147
Similar to the distributed nature of CAS having a direct impact on the design process
by presuming interface synthesis and integration activities, this is equally true for the
safety engineering process. Although the automotive safety standard ISO 26262
describes the Safety Element out of Context (SEooC) [12] concept for tackling safety
interface abstraction, it cannot be applied as-is to CAS, because it primarily addresses
the challenges of distributed development from the perspective of supplier companies
providing general-purpose software and hardware components to vehicle vendors. The
scope of SEooC is thus not to dynamically monitor safety properties and perform reac‐
tions during runtime, but to facilitate reuse of software and hardware components at
design time. However, the SEooC recommendation to make safety-related assumptions
of a component explicit in a modular way can be used as a starting point for formalizing
safety-related assumptions in the context of CAS.
Although the evaluations conclude that future cooperative systems such as Car2X will
have to follow service-based design principles for the description of functionality,
concrete guidelines are missing on how to systematically embed service-oriented design
approaches into state-of-the-art safety engineering processes. This is especially true for the
model-based synthesis of runtime service interfaces incorporating safety information.
The service-oriented approach presented in this paper aimed at marking an engi‐
neering starting point for the subsequent derivation of ConSert runtime models.
ConSerts as described in [2] were used to check during runtime integration of several
constituent systems into a CAS, whether the given set of configurations can yield a safe
CAS behavior at all. If no safe combination of configurations exists after the ConSert
composition and evaluation, the CAS formation is rejected. However, the description
of externally visible behavior at the service (and safety) interface as described in this
paper paves the way for more dynamic reactions to environmental or structural changes
during operation of the CAS (i.e., when the CAS is already collaborating). This first
includes the runtime monitoring of the environmental context (e.g. changing weather or
road surface conditions) as well as the CAS structure and capabilities (e.g. changing
configurations due to system failures or reconfiguration of constituent systems). After
a change has been detected, its effect onto the fulfillment of CAS safety goals has to be
evaluated. The resulting safety demands, which have to be fulfilled by the CAS, are
matched against the currently possible safety guarantees the CAS can currently give
(determined via classical ConSert evaluation plus the check of safety-related assump‐
tions fulfillment). If there is a mismatch between required safety demands (for a given
environmental context) and given safety guarantees (for a given system topology and
capabilities), reconfiguration strategies have to be executed for the CAS to remain fail-
operational. The described activities represent the well-known MAPE cycle (Monitor –
Analyze – Plan – Execute), applied to dynamic runtime safety assurance. The respective
conceptual framework has been introduced under the term Dynamic Safety Management
(DSM) in [13]. While ConSerts as described in [2] focus mainly on the determination
of currently valid safety guarantees of the CAS, DSM embeds the ConSerts approach
into a larger context by adding conceptual links to safety-related context monitoring,
dynamic risk management and dynamic risk control, which includes the execution of
safety-driven adaptation mechanisms.
148 J. Reich and D. Schneider
4 Conclusion and Future Work
To enable a safe cooperation of CAS at runtime based on runtime safety models such
as ConSerts, we believe that a continuous model-based approach needs to be established
allowing for a (semi-)automated synthesis of runtime safety models from design time
safety models emerging from traditional safety engineering activities such as fault tree
analysis or safety concept models. As all safety engineering activities focus on malfunc‐
tional deviations of the intended functional behavior of a system, the first open question
was to examine how the functional behavior of CAS applications has to be modeled to
effectively prepare the safety analysis and the formulation of black-box behavioral
deviation bounds in shape of safety guarantees and demands.
In this paper, we first gave an overview on the principal activities that have to be
carried out during CAS development from CAS application design to the eventual
runtime integration. Next, we focused on the service-oriented function refinement of
CAS applications and explained the major benefits of service-oriented refinement over
data-flow-oriented refinement when aiming for a modular description of functional
black-box interfaces. Finally, we described the allocation of functions to a concrete
structure of systems and their components leading to a set of system interfaces. We
identified five different system interface types leading to different required properties
and challenges for their synthesis and integration at both design and runtime.
With a defined CAS functional behavior and its allocation to systems and compo‐
nents as a basis, we plan as future work to perform service-oriented safety analyses to
identify safety-critical deviations and consider the impact that the interface types iden‐
tified in this paper have on this task. Furthermore, we will investigate the degree of how
much information about employed safety mechanisms needs to be transferred into
runtime to allow a successful and safe integration of CAS runtime interfaces in the field.
Acknowledgements. The work presented in this pap er was created in context of the DEIS Project
(Dependability Engineering Innovation for CPS), which is funded by the European Commission
(Grant Agreement No. 732242).
References
1. Proff, H., Schönharting, J., Schramm, D., Ziegler, J.: Zukünftige Entwicklungen in der
Mobilität. Springer, Wiesbaden (2012, in German). https://doi.org/
10.1007/978-3-8349-7117-3
2. Schneider, D., Trapp, M.: Engineering conditional safety certificates for open adaptive
systems. IFAC Proc. Vol. 46(22), 139–144 (2013)
3. Kural, E., Jones, S., Parrilla, A., Grauers, A.: Traffic light assistant system for optimized
energy consumption in an electric vehicle. In: International Conference on Connected
Vehicles and Expo (ICCVE), Vienna, Austria, pp. 604–611 (2014)
4. Back, R.J.R., Sere, K.: Superposition refinement of reactive systems. Formal Aspects
Comput. 8, 324–346 (1996)
Towards (Semi-)Automated Synthesis of Runtime Safety Models 149
5. Feth, P., Adler, R.: Service-based modeling of cyber-physical automotive systems: a
classification of services. In: Workshop CARS 2016 – Critical Automotive Applications:
Robustness and Safety (2016)
6. Schneider, D.: Conditional Safety Certification for Open Adaptive Systems. Doctoral thesis,
Fraunhofer IRB Verlag, Germany (2014). ISBN:383960690X 9783839606902
7. Avizienis, A., Laprie, J.-C., Randell, B., Landwehr, C.: Basic concepts and taxonomy of
dependable and secure computing. IEEE Trans. Dependable Secure Comput. 1(1), 11–33
(2004)
8. Schneider, D., et al.: WAP: digital dependability identities. In: IEEE 26th International
Symposium Software Reliability Engineering (ISSRE), pp. 324–329 (2015)
9. Eckel, A., et al.: State of the art and SoA architecture requirements report. Edited by EMC2
Project Consortium (2014)
10. Röckl, M., Gacnik, J., Schomerus, J.: Integration of Car-2-Car communication as a virtual
sensor in automotive sensor fusion for advanced driver assistance systems. In: Proceedings
of FISITA 2008. Springer Automotive Media (2008)
11. Wagner, M., Zobel, D., Meroth, A.: SODA: serv ice-oriented architecture for runtime a daptive
driver assistance systems. In: 2014 IEEE 17th International Symposium on Object/
Component/Service-Oriented Real-Time Distributed Computing. Institute of Electrical and
Electronics Engineers (IEEE) (2014)
12. International Organization for Standardization: ISO 26262-10 Clause 9: Road Vehicles -
Functional Safety – Safety Element out of Context Development (2010)
13. Trapp, M., Weiss, G., Schneider, D.: Towards safety-awareness and dynamic safety
management. In: Proceedings of IEEE 14th European Dependable Computing Conference
(EDCC) (2018, to be published)
150 J. Reich and D. Schneider
... However, reality is that either a constrained is required, or × ↦ tolerance is an acceptable trait of the system. There are examples of this pessimistic approach is currently evolving [26]. There is also an analogue in the notion of monitoring Trustworthiness of systems [27] that may also be applicable. ...
... You will also notice that the automobile industry, have set levels of automaton, as likely surreptitiously play on mitigations for moral disengagement on their part. This passes risk acceptance 25 to motorist users because there are "rules" 26 . The is no rule, however, that rules for similar levels of automation in aerospace need move over to the motoring public. ...
Preprint
Full-text available
In this paper I provide a conceptual model useful for describing the cyclic interactions of a system or a system-of-system with its environment and with the enterprises operating it. What spills out is a model that also provides a conceptual model for Artificial Intelligence assurance, where the paradigm is based upon Belief, Desire and Intention (BDI). When one notes that Multi-Agent Systems (MAS) based BDI based agency have an affinity with SoS, Safety Organisations and vice versa, then it is indeed a small world. To achieve this, the paper describes how, using ideas from POE and AOE, undesirable events introduced at operation time and/or at design time can interact, possibly leading to forbidden, optional or allowed states. Using a conceptual model for intentional and temporal reasoning, constraints can be defined to steer the model towards an ALARP outcome. The model leverages off the basis for the proper design and analysis of safety-critical systems with human and computer-based components per Hall and Silva. Per the model provided by Hall and Silva, the model in this paper retains its requirements engineering reference model of Zave and Jackson. The model in this paper includes the additions by Hall and Silva of behavioural dynamics, the inclusion of an operator and feedback, and would have that extended out to the enterprise. The model in this paper incorporates theoretics from goal-oriented requirement engineering to integrate ideas from STPA and FRAM into a conceptual model that aims to provide phased justifications, of Missionality and not just Safety. These justifications, hopefully, as side effects of the design process. The model suggested by Hall and Silva considers problems not as the chaining of events but as the chaining of deviations from design, from operation and from their interaction. This can act as a heuristic when modelling design solutions with a range of lightweight goal-oriented requirement engineering notations. My goal is a model that preserves the attempt by Hall and Silva to encourage analyses that transcend the traditional reductionist approach in event-chain models can be conducted, but spanning cognitive, system and not just software engineering.
... Conventionally, functional models contain data and information flow connectors between sensing, control and actuation functions. In [7], an approach for the service-oriented definition of cause-effect relationships has been presented, which better supports the derivation of modular failure mode interfaces than purely dataflow-oriented models. As we will see, modularity is a necessary property for the derivation of runtime DDIs. ...
Chapter
Full-text available
Cyber-Physical Systems (CPS) harbor the enormous potential for societal improvement in terms of safety, comfort and economic efficiency. However, these benefits will only be unlocked if the safety of these systems can be assured with a sufficient level of confidence. Traditional safety engineering and assurance approaches alone cannot address the CPS-inherent uncertainties and unknowns induced by openness and adaptivity. Runtime safety assurance approaches such as Conditional Safety Certificates (ConSerts) represent novel means to cope with CPS assurance challenges by introducing modular and formalized safety arguments with variant support, thereby shifting the final safety certification step to runtime. However, the systematic engineering of ConSerts at design-time is a complex task which, up to now, has not been sufficiently addressed. Without systematic safety assurance at both design-time and runtime, CPS will hardly be assurable with acceptable confidence given the uncertainties and unknowns. In this paper, we present an engineering method for synthesizing ConSerts based on Digital Dependability Identities (DDI). The approach is demonstrated for a cooperative vehicle platooning function (CACC) from an industrial case study.
... Conventionally, functional models contain data and information flow connectors between sensing, control and actuation functions. In [7], an approach for the service-oriented definition of cause-effect relationships has been presented, which better supports the derivation of modular failure mode interfaces than purely dataflow-oriented models. As we will see, modularity is a necessary property for the derivation of runtime DDIs. ...
Preprint
Full-text available
Cyber-Physical Systems (CPS) harbor the enormous potential for societal improvement in terms of safety, comfort and economic efficiency. However, these benefits will only be unlocked if the safety of these systems can be assured with a sufficient level of confidence. Traditional safety engineering and assurance approaches alone cannot address the CPS-inherent uncertainties and unknowns induced by openness and adaptivity. Runtime safety assurance approaches such as Conditional Safety Certificates (ConSerts) represent novel means to cope with CPS assurance challenges by introducing modular and formalized safety arguments with variant support, thereby shifting the final safety certification step to runtime. However, the systematic engineering of ConSerts at design-time is a complex task which, up to now, has not been sufficiently addressed. Without systematic safety assurance at both design-time and runtime, CPS will hardly be assurable with acceptable confidence given the uncertainties and unknowns. In this paper, we present an engineering method for synthesizing ConSerts based on Digital Dependability Identities (DDI). The approach is demonstrated for a cooperative vehicle platooning function (CACC) from an industrial case study.
Conference Paper
Full-text available
In recent years, we have witnessed a strong trend towards more openness and adaptivity in many application domains of computer-based systems. In this context, the assurance of a sufficient level of safety poses serious challenges because traditional engineering and assurance approaches are usually not applicable without further ado. In order to meet these challenges, we recently introduced a framework that enables runtime safety certification based on conditional safety certificates (ConSerts). Since the definition of ConSerts relies on an adequate safety engineering backbone, we now present an engineering approach for defining ConSerts based on established safety engineering processes and techniques. The presented approach has been evaluated in an industry project in form of a feasibility study in the agricultural domain.
Article
Full-text available
This paper gives the main definitions relating to dependability, a generic concept including a special case of such attributes as reliability, availability, safety, integrity, maintainability, etc. Security brings in concerns for confidentiality, in addition to availability and integrity. Basic definitions are given first. They are then commented upon, and supplemented by additional definitions, which address the threats to dependability and security (faults, errors, failures), their attributes, and the means for their achievement (fault prevention, fault tolerance, fault removal, fault forecasting). The aim is to explicate a set of general concepts, of relevance across a wide range of situations and, therefore, helping communication and cooperation among a number of scientific and technical communities, including ones that are concentrating on particular types of system, of system failures, or of causes of system failures.
Conference Paper
Increasingly intelligent vehicle driving systems are rapidly being developed, and will in the future become a necessity for sustainable, convenient and safe mobility in our ever more urbanized world. This paper presents an innovative approach for the control of a fully electric vehicle approaching a road segment with Multiple Traffic Lights (TL). By utilizing Vehicle to Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communication, the energy consumption for the maneuver completion can be reduced. The problem is approached from a Model Predictive Control (MPC) framework. The performance of the system is evaluated using a complex simulation toolchain representing the vehicle, powertrain, driver, and road including the traffic conditions. The results have shown an overall energy consumption reduction of 29 % for an idealized case and 17 % for a real road simulated scenario as compared to ‘normal’ human driver behavior.
Conference Paper
Cyber-Physical Systems (CPS) provide enormous potential for innovation but a precondition for this is that the issue of dependability has been addressed. This paper presents the concept of a Digital Dependability Identity (DDI) of a component or system as foundation for assuring the dependability of CPS. A DDI is an analyzable and potentially executable model of information about the dependability of a component or system. We argue that DDIs must fulfill a number of properties including being universally useful across supply chains, enabling off-line certification of systems where possible, and providing capabilities for in-field certification of safety of CPS. In this paper, we focus on system safety as one integral part of dependability and as a practical demonstration of the concept, we present an initial implementation of DDIs in the form of Conditional Safety Certificates (also known as ConSerts). We explain ConSerts and their practical operationalization based on an illustrative example.
Conference Paper
Unlike state-of-the-art Driver Assistance Systems (DAS) upcoming technologies may not base on a static software and system architecture. This is especially true for DAS for truck and trailer combinations were the components needed are distributed over both parts of the articulated vehicle. As a truck might be connected to different trailers changes are very common. In order to handle these changes at runtime the usage of Serviceoriented Architecture (SOA) is a promising approach. Using this principle the functionalities are encapsulated into Services which are Re-Orchestrated whenever the system architecture changes. Since the Services in such a system run on small embedded units and are connected through specialized network systems existing SOA frameworks cannot be used here. This paper introduces SODA, a tailored SOA middleware and development process to design runtime adaptive DAS for truck and trailer combinations using Services.
Article
In recent years it has become more and more evident that openness and adaptivity are key characteristics of next-generation distributed systems. The reason for this is not least due to the advent of computing trends like ubiquitous computing, ambient intelligence, and cyber-physical systems, where systems are usually open for dynamic integration and able to react adaptively to changing situations. Despite being open and adaptive, it is a common requirement for such systems to be safe. However, traditional safety assurance techniques, both state-of-the-practice and state-of-the-art ones, are not sufficient in this context. We have recently developed some initial solution concepts based on conditional safety certificates and corresponding runtime analyses. In this article we show how to operationalize these concepts. To this end, we present in detail how to specify conditional safety certificates, how to transform them into suitable runtime models, and how these models finally support dynamic safety evaluations.
Article
Die Elektromobilität ist zurzeit ein beherrschendes Thema nicht nur in den Forschungs- und Entwicklungsbereichen nahezu aller Automobilhersteller und -zulieferer sondern auch in der gesamten Gesellschaft. Ursächlich hierfür ist das große Potential, welches diese Technologie hinsichtlich Umweltschutz und Ressourcenschonung bietet.
Conference Paper
Advanced driver assistance systems (ADAS) require a comprehensive and accurate situation model. Often in-vehicle sensors do not provide sufficient quality and quantity of information to fulfill the demanding requirements. Car-2-Car communication can be seen as an adaptive sensor that provides additional information regularly but also on demand. Due to the fact that Car-2-Car communication strongly depends on the penetration rate, we argue for a seamless integration of Car-2-Car communication as an additional sensor in automotive sensor fusion. With increasing penetration rate the sensor fusion will significantly benefit and eventually unfold its full potential. Due to the fundamentally different measuring principles of in-vehicle sensors and information provided by Car-2-Car communication, redundancy and complementarity can be leveraged to a great extent, thus, increasing accuracy, reliability and robustness of the situation assessment. In addition to a detailed description of the fusion algorithm this paper outlines DLR’s system architecture for ADAS and an enhanced ACC as an application example to show the potential of our approach.