=Paper=
{{Paper
|id=Vol-2060/mekes9
|storemode=property
|title=On the Use of Orthogonal Context Uncertainty Models in the Engineering of Collaborative Embedded Systems
|pdfUrl=https://ceur-ws.org/Vol-2060/mekes9.pdf
|volume=Vol-2060
|authors=Torsten Bandyszak,Patrick Kuhs,Jasmin Kleinblotekamp,Marian Daun
|dblpUrl=https://dblp.org/rec/conf/modellierung/BandyszakKKD18
}}
==On the Use of Orthogonal Context Uncertainty Models in the Engineering of Collaborative Embedded Systems==
https://ceur-ws.org/Vol-2060/mekes9.pdf
Ina Schaefer, Loek Cleophas, Michael Felderer Nachname
(Hrsg.): 2018,
< Buchtitel>,
Modellierung
Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 121
in der Entwicklung von kollaborativen eingebetteten Systemen (MEKES) 15
On the Use of Orthogonal Context Uncertainty Models in
the Engineering of Collaborative Embedded Systems
Torsten Bandyszak1, Patrick Kuhs1, Jasmin Kleinblotekamp1, Marian Daun1
Abstract: Collaborative embedded systems operate in highly dynamic and uncertain contexts. For
instance, in vehicle platooning, several embedded systems form a collaborating group. Among
others, they have to cope with unclear intentions of collaborators, uncertainties caused by
imperfect technology, and the inherent indeterminacy in the physical surroundings. Hence, it is
crucial to systematically consider and model context uncertainty during the development of these
systems. Existing uncertainty modeling approaches mainly focus on one specific artifact type, and
do not consider the need for supporting purpose-driven abstractions and corresponding
perspectives on a system’s operational context. In this paper, we build upon the SPES XT Context
Modeling Framework, which employs three different perspectives, each using a specific diagram
type. Based on state-of-the-art concepts related to uncertainty, we investigate the use of capturing
uncertainty in separate, orthogonal models, and establish relations to the three different context
perspectives. We illustrate our promising results using a vehicle platooning scenario.
Keywords: Collaborative embedded systems, Uncertainty, Orthogonal modeling, Context
modeling, Requirements engineering
1 Introduction
Nowadays, embedded software systems are increasingly interconnected in order to
realize more complex functionality and thus achieve higher goals that a single embedded
system is not able to achieve on its own. For instance, car platooning is an application
area where several systems form dynamic, collaborating groups aiming at avoiding
traffic jams and increase safety as well as driving comfort (cf., e.g., [Ji16]). Cooperative
Adaptive Cruise Control (CACC) systems [Fe16] are supposed to use inter-vehicle
communication and exchange of information to enhance platooning functionalities and
automate typical platooning maneuvers such as joining or leaving a platoon. Such
collaborative embedded systems operate in highly dynamic contexts, and thus have to
cope with various uncertainties related to the context and interactions between different
CACC systems in a platoon. These uncertainties often indicate potential safety hazards,
and play an important role in safety and risk assessments [Ax17]. Therefore, it is crucial
to systematically consider and model context uncertainty during the development of
these systems. In general, handling uncertainty is a major challenge in system
development, and there are various definitions of uncertainty available in the literature
(see, e.g., [RJC12] for a compilation of uncertainty sources).
1
University of Duisburg-Essen, paluno – The Ruhr Institute for Software Technology, Gerlingstr. 16, 45127
Essen, {Torsten.Bandyszak; Patrick.Kuhs; Jasmin.Kleinblotekamp; Marian.Daun}@paluno.uni-due.de
122 Torsten
16 TorstenBandyszak
Bandyszak, Patrick Kuhs, Jasmin Kleinblotekamp, Marian Daun
et al.
Several approaches towards documenting uncertainty in a model-based manner have
been proposed. Typically uncertainty information is documented in engineering artifacts,
for instance, by annotating missing information in partial models [FaSa13], or capturing
uncertainty factors in goal models (e.g., [Ch09]). Recently, Zhang et al. [Zh17b]
proposed a comprehensive UML profile, which allows capturing a wide range of
uncertainty information. However, these approaches do not explicitly account for
consistently tracing uncertainty information through different views on the system to be
developed, and its context. In requirements engineering, usually three different
perspectives are distinguished: the structural perspective, the functional perspective, and
the behavioral perspective [JD91]. These three perspectives are also suitable for
systematically modelling the operational context of embedded systems, i.e., the context
in which they operate at runtime [Da16]. Documenting relevant uncertainty information
in each of these three context perspectives easily results in complex models that are hard
to understand, quite similar to the management of variability information in the
development of software product lines (see [Ba03]). This is particularly the case for
collaborative embedded systems as models of these systems are already large on their
own. Furthermore, uncertainty information is often documented redundantly, since there
is no separate, dedicated artifact capturing uncertainties.
This paper investigates the use of orthogonal uncertainty modeling techniques in the
engineering of collaborative embedded systems that need to operate in highly dynamic,
uncertain contexts. To this end, we illustrate the possibilities of orthogonal uncertainty
modelling, based on the SPES XT Context Modeling Framework [Da16] and a subset of
uncertainty concepts taken from the comprehensive taxonomy of uncertainty proposed
by Zhang et al. [Zh16]. The key solution idea is to handle uncertainty as a cross-cutting
concern that manifests in different diagram types, similar to variability (cf., e.g., [Sc16]).
For modeling uncertainties in an orthogonal manner, we use SysML Requirements
Diagrams. Relationships are established to context models from the three perspectives
mentioned above. We illustrate the orthogonal modeling approach using a case example
focused on one particular platooning scenario, i.e., the joining maneuver, where a
vehicle joins a platoon. First results show that our orthogonal approach aids the
systematic documentation and analysis of context uncertainties.
In Section 2, an overview of fundamental approaches and existing works related to our
approach is given. Section 3 introduces the case example and illustrates uncertainties
within a specific platooning scenario. In Section 4, we describe our approach towards
orthogonal context uncertainty modelling. Finally, Section 5 concludes the paper.
2 Fundamentals and Related Work
This section briefly introduces the SPES XT Context Modeling Framework, and
provides an overview of existing approaches towards uncertainty modelling.
On the Use of Orthogonal Context Uncertainty Models in the Engineering of Collaborative
Embedded
Orthogonal Context Systems
Uncertainty Models 123
17
2.1 SPES XT Context Modeling Framework
The SPES XT Context Modeling Framework [Da16] allows for seamlessly integrating
context models into the development of embedded systems. It separates the context of
knowledge, which comprises sources of knowledge relevant for system development,
from the operational context, i.e., the context in which a system is embedded at runtime.
The latter is in focus of this paper, and briefly summarized here.
Based on a well-established classification in requirements engineering (cf. [JD91]), the
operational context is structured into the following three distinct perspectives: The
structural operational context focuses on physical context objects that interact with the
system at runtime. Here, static structures and relationships are modeled, for instance,
using SysML Block Definition Diagrams. In contrast, the functional operational context
employs functional modelling languages, e.g., based on UML Activity Diagrams, in
order to abstract from static properties of context objects, and focus on the functionality
they provide. Dependencies between context functions and the system’s functions can
also be modeled. The third perspective, i.e., the behavioral operational context, allows
for modeling the externally observable behavior of context objects. To this end,
automata-based modeling languages such as state machines can be used.
2.2 Approaches for Modelling Uncertainty
Coping with uncertainty is a challenge that has increasingly attracted interest, most
notably in the areas of self-adaptive systems (e.g., [Ch09, RJC12]), and in cyber-
physical systems (c.f. [Zh16]). There are also some theories distinguishing fundamental
kinds of uncertainties (e.g., [Wa03]). Several approaches towards formal modelling of
uncertainties are available, the most prominent ones being probabilistic approaches,
which can express the likelihood that some event will happen or some property holds,
and fuzzy-logic approaches, where uncertainty is expressed as a degree of truth (see
[RAC04]). For example, Markov chains are widely used in engineering to model state
transitions triggered with a certain probability. Some authors focus on documenting
contextual uncertainty in goal models. For instance, Cheng et al. [Ch09] use the obstacle
notation to model uncertainties in KAOS models. The authors of [WS10] use the claim
concept to document uncertain assumptions, their interrelations, as well as the effect on
system goals. Other approaches deal with incorporating uncertainty in natural-language
requirements [Wh09], incorporating the fuzziness of real-world data in UML Class
Diagrams [MZY16], or annotating missing information in partial models [FaSa13].
Zhang et al. [Zh16] present a comprehensive conceptual model to structure different
kinds of uncertainties. Their approach emphasizes the subjective notion of uncertainty,
i.e., uncertainties are always related to statements about beliefs of some agent. In their
taxonomy the core concepts to further characterize an uncertainty can be summarized as
follows: Uncertainty has a specific type that captures about what there exists a lack of
confidence, e.g., regarding the content of some other entity’s subjective belief
124 Torsten
18 TorstenBandyszak
Bandyszak, Patrick Kuhs, Jasmin Kleinblotekamp, Marian Daun
et al.
statements. Uncertainty becomes visible in some position or artifact (i.e., locality), and
occurs according to a specific pattern (e.g., it may be persistent, or occurring
sporadically). Uncertainty also has an effect and a risk associated with it. Furthermore,
uncertainty can be measured, e.g., using probabilistic approaches (see above). The
detailed uncertainty-related concepts are beyond the scope of this paper; for details
please refer to [Zh16]. In [Za17a], some uncertainty concepts are applied to enhance
textual use case specifications with uncertainty information. There is also a UML profile
available that comprises stereotypes reflecting the different uncertainty concepts
[Zh17b]. However, to the best of our knowledge, there is no approach that explicitly
addresses the need for tracing uncertainty information through several engineering
artifacts, such as context models, or requirements and architecture models.
3 Uncertainties in the Vehicle Platooning Example
This section introduces the join maneuver as the specific scenario for illustrating our
approach. Based on this scenario, it is shown how uncertainty can be characterized.
3.1 The Join Maneuver in Vehicle Platooning
We use the join protocol described in [Se14], and information about the context of a
conventional ACC from [Da16] as a reference for identifying uncertainties as well as for
creating the models presented in Section 4. The joining maneuver is based on the
assumption that all the vehicles potentially engaging in a platoon are equipped with a
CACC that is able to manage, among others, the joining procedure. A platoon is always
led by one vehicle, which is denoted the platoon leader. The specific focus is on the case
where a vehicle joins in the middle of the platoon. There are several possible variations
as well as additional joining scenarios under certain conditions; these are, however, not
considered here in order to keep the models simple. The basic joining maneuver consists
of the following essential steps: First, the joining vehicle sends a join request after
discovering the platoon. Then, the platoon leader computes a potential joining position in
the platoon, and decides whether to accept or refuse the request. In case the request is
accepted, the leader replies a positive acknowledge, as well as information about the
position where to join in the platoon. The joining vehicle approaches the joining
position, and notifies the platoon leader accordingly. Next, the platoon leader sends a
command to the vehicle, which is supposed to open a gap for the joining vehicle. In
order to open a gap, the vehicle that received the command for opening a gap notifies all
the following vehicles that it temporarily forms a second platoon. Eventually this
temporary platoon reduces its speed to open a gap, and notifies the leader that a gap has
been formed. The leader then coordinates the joining vehicle to change the lane into the
gap. When done, the successfully joined vehicle notifies the leader so that the second
platoon can be commanded to close the gap and thereby integrate the temporary platoon
back into the original one. More details on the join maneuver can be found in [Se14].
On the Use of Orthogonal Context Uncertainty Models in the Engineering of Collaborative
Embedded
Orthogonal Context Systems
Uncertainty Models 125
19
3.2 Identifying Uncertainty Information
Since the context of a CACC system is highly dynamic, and not only includes
collaboration-related aspects (e.g., communication among different CACC embedded in
different vehicles), but also the physical surroundings (e.g., road and weather
conditions), it is characterized by several uncertainties that may occur during operation.
In the joining maneuver, one important uncertainty concerns the potentially ambiguous
information (cf. [RJC12]) from different sources, regarding a potential gap for joining
the platoon. While the command and joining position received from the platoon leader
indicates a free gap, the data obtained from a camera sensor might suggest that there
actually is an object in the gap. For instance, a vehicle not part of the platoon may have
joined in the gap (cf. [Se14, Ax17]). In this case there is a severe uncertainty whether the
gap is open or not. This context uncertainty prevents the CACC to operate properly.
In Tab. 1, we describe this context uncertainty in detail. The uncertainty concepts are
borrowed from [Zh16] (see also Section 2.2), while the way of documenting the
information is inspired by the approach to specifying uncertainties in textual use case
descriptions described in [Zh17a]. Please note that, in order to keep things simple, we do
not use all the concepts related to uncertainty defined in [Zh16, Zh17b].
Uncertainty 1: Ambiguous information from different sources
Kind Environment, Content
Indeterminacy Source Intentions of collaborators, Sensor imprecision, Communication
failures
Locality Gap information, Object recognition
Effect Unable to change lane
Risk High
Occurrence Pattern Aperiodic
Tab. 1: Documentation of Uncertainty Information
The kind of uncertainty denotes that the uncertainty represents lack of confidence
regarding the current state of the environment and the content of messages exchanged in
a platoon. The locality, i.e., the artifact where the uncertainty becomes visible, is the gap
information distributed by the platoon leader, and the data coming from the vehicles own
sensors, which need to be compared by the CACC at runtime. The indeterminacy source
that causes the ambiguity is rooted in unclear intentions of collaborators as well as the
inherent imperfection of sensor and communication technology (cf. [RJC12]). The
ambiguity, in turn, prevents the vehicle from safely changing the lane, if not properly
handled. The risk associated with this uncertainty is high since some inappropriate action
taken by the CACC in the presence of this uncertainty may pose a safety hazard. The
occurrence pattern of the uncertainty is characterized as aperiodic as the uncertainty can
only occur when a vehicle intends to join the platoon, i.e., it is event-triggered.
126 Torsten
20 TorstenBandyszak
Bandyszak, Patrick Kuhs, Jasmin Kleinblotekamp, Marian Daun
et al.
4 Orthogonal Uncertainty Modelling
In order to relate the uncertainties defined in Section 3.2 to context models of the CACC
system, we suggest modelling the uncertainty information in a dedicated diagram that is
orthogonal to the operational context models of the SPES XT Context Modeling
Framework [Da16]. Since the scope of this paper is to motivate the use of orthogonal
modelling techniques for documenting uncertainties, we do not propose a new modelling
language. Instead, we use SysML Requirements Diagrams to depict uncertainty. In the
following, we will introduce diagrams from the three context perspectives, and illustrate
traceability relationships between them and the orthogonal uncertainty model.
[soc] <> Structural Operational Context
On-Board Camera Unit
Platoon Radar Unit
Unit
1 1 Object Distance
recognition
1 1..*
Accelerate /
Platoon becomes Merging Cooperative Decelerate Engine
Leader Follower
«Context Entity Vehicle ACC Control Unit
Association»
Platoon messages Steering
and information Command
V2V Steering
connected to
Vehicle Communication
«Context Entity Association»
Network Unit
Fig. 1: Uncertainty Information in Structural Operational Context Models
The structural model of the CACC’s operational context shown in Fig. 1 depicts the
CACC as the system under development (the context subject), and its relations to other
control units (such as a Camera Unit, or the Engine Control Unit) onboard the vehicle
that wants to join an existing platoon. The model also gives a structural perspective on
the formation of a platoon, which consists of one leader and several followers.
The orthogonal uncertainty model comprising the ambiguity described in Section 3.2 is
depicted at the bottom of Fig. 1. The relationships between the uncertainty concepts and
On the Use of Orthogonal Context Uncertainty Models in the Engineering of Collaborative
Embedded
Orthogonal Context Systems
Uncertainty Models 127
21
elements of the context model are depicted using dotted lines. This allows tracing
uncertainty-related information to the model elements that are affected by or subject to
uncertainties. For example, the two specific aspects of the uncertainty locality manifest
in the interfaces between the CACC and the Camera Unit, and the V2V Communication
Network, respectively ( and ). Sensor imprecision as a reason for potential
mismatches between the two information sources (i.e., the ambiguity) is related to the
Camera Unit and the Radar Unit (), while Communication failures relate to the V2V
Communication Network used for realizing the exchange of messages in the platoon ().
The uncertainty model also allows specifying relationships between uncertainties (cf.
[Zh17a]). For instance, another uncertainty “Inaccurate object recognition”, which is not
specified in detail to ease readability, is typically one cause of ambiguity related to
imperfect sensor technology. As another example, an unknown number of vehicles in the
platoon can be seen as a factor that increases or amplifies the ambiguity uncertainty.
Fig. 2: Uncertainty Information in Functional Operational Context Models
Fig. 2 shows a functional operational context model and its relations to the same
orthogonal uncertainty model. Here, relations and depict the same aspect as the
respective relations in the structural operational context model (see Fig. 1), however,
from a functional perspective that highlights the input/output data relations between the
CACC’s functions and context object functions (depicted using dashed lines). The same
applies to communication failures (). Furthermore, the effect of the uncertainty, i.e.,
128 Torsten
22 TorstenBandyszak
Bandyszak, Patrick Kuhs, Jasmin Kleinblotekamp, Marian Daun
et al.
the inability to change the lane, will impact the CACC function “Control Lane Change”
(). Unknown intentions of collaborators, which constitute another indeterminacy
source, could manifest in a delayed gap opening (). Unclear intentions are specifically
important if CACC implementations by different vendors are supported.
Fig. 3: Uncertainty Information in Behavioral Operational Context Models (based on [Se14])
The state machine diagrams in Fig. 3, which closely reflect the protocol automata
presented in [Se14], take a behavioral view on the case example. The upper diagram
presents the behavior of the context object “Platoon leader”, while the diagram at the
bottom presents a behavioral requirements model describing the CACC. The inability to
complete the join (i.e., to change the lane) in the presence of uncertainty may cause a
deadlock in the behavior of the platoon leader (), which will require certain handling
mechanisms, such as timeouts (see [Se14]). It also prevents the action “Change lane” to
be carried out by the CACC (). Relation denotes that communication failures
caused by imperfect technology may also negatively influence the exchange of request
and acknowledgement messages. Relation specifies the occurrence trigger of the
uncertainty, which is the detection of a platoon, accompanied by a join request.
On the Use of Orthogonal Context Uncertainty Models in the Engineering of Collaborative
Embedded
Orthogonal Context Systems
Uncertainty Models 129
23
Fig. 3 highlights an important aspect of our orthogonal uncertainty modeling approach,
i.e., the fact that uncertainty does not only reflect in context models, but also affects
requirements models (see relations and ). Similarly, architectural artifacts or source
code might be associated with the same uncertainty using our orthogonal model. This
also allows specifying additional requirements for mitigating potential hazardous effects
of uncertainties, which is especially relevant for safety-critical systems.
5 Conclusion and Outlook
In this paper, we investigated the use of orthogonal models for documenting uncertainty.
To do so, we exemplarily modelled orthogonal uncertainty information related to the
context of an exemplary CACC system, with a particular focus on the procedure to
coordinate the joining of a vehicle into a platoon. The information we capture in the
orthogonal uncertainty models is based on state-of-the-art concepts relevant for
uncertainty. We established relations between the orthogonal uncertainty model and
context models from three different perspectives. The results show that orthogonal
uncertainty modeling can reduce redundancies, and enhances the traceability of
uncertainty information. The latter is essential for properly considering and mitigating
potential runtime uncertainties, so that the system will satisfy its requirements in an
uncertain operational context. Orthogonal uncertainty modeling is seen as advantageous
in early development phases, and also has the potential to support safety analyses.
In future works, we aim at establishing an orthogonal uncertainty modeling language,
including a suitable notation, as an extension of the SPES XT Context Modeling
Framework. This extension will be based on a sound theoretical basis, i.e., an ontology
that captures the specific characteristics of collaborative embedded systems as well as
related uncertainties. To this end, we will investigate the use of more sophisticated
uncertainty modeling concepts, e.g., from the comprehensive taxonomy presented in
[Zh16]. The semantics of the relationships between the uncertainty model and context
models also needs to be further elaborated. Moreover, methodological aspects, i.e.,
guidelines for coping with uncertainties, as well as the integration of orthogonal
uncertainty models into hazard analyses and software process models, will be analyzed.
Acknowledgements. This research has been partly funded by the German Federal
Ministry of Education and Research under grant no. 01IS16043V.
References
[Ax17] Axelsson, J.: Safety in Vehicle Platooning: A Systematic Literature Review. In: IEEE
Trans. on Intelligent Transportation Systems, Vol. 18 (5), pp. 1033–1045. IEEE, 2017.
[Ba03] Bachmann, F. et al.: A Meta-model for Representing Variability in Product Family
Development. In: PFE 2003, LNCS 3014, pp. 66–80. Springer, 2004.
130 Torsten
24 TorstenBandyszak
Bandyszak, Patrick Kuhs, Jasmin Kleinblotekamp, Marian Daun
et al.
[Ch09] Cheng, B.H.C. et al.: A Goal-Based Modeling Approach to Develop Requirements of
an Adaptive System with Environmental Uncertainty. In: MODELS 2009, LNCS
5795, pp. 468–483. Springer, 2009.
[Da16] Daun, M. et al.: SPES XT Context Modeling Framework. In: Advanced Model-Based
Engineering of Embedded Systems – Extensions of the SPES 2020 Methodology, pp.
43–57. Springer, 2016.
[FaSa13] Famelis, M., Santosa, S.: MAV-Vis: A Notation for Model Uncertainty. In: 5th Int.
Workshop on Modeling in Software Engineering (MiSE), pp. 7–12. IEEE, 2013.
[Fe16] U.S. Federal Highway Administration: Cooperative Adaptive Cruise Control - Taking
Cruise Control to the Next Level. Fact Sheet FHWA-HRT-16-044, Feb. 2016.
[JD91] Jordan, K.A., Davis, A.M.: Requirements Engineering Metamodel - An Integrated
View of Requirements. In: COMPSAC 1991, pp. 472–478. IEEE, 1991.
[Ji16] Jia, D. et al.: A Survey on Platoon-Based Vehicular Cyber-Physical Systems. In: IEEE
Comm. Surveys & Tutorials, Vol. 18, No. 1, 2016, pp. 263–284. IEEE, 2016.
[MZY16] Ma, Z.M., Zhang, F., Yan, L.: Fuzzy Information Modeling in UML Class Diagram
and Relational Database Models. In: Applied Soft Computing 11, pp. 4236–4245.
Elsevier, 2016.
[RAC04] Ranganathan, A., Al-Muhtadi, J., Campbell, R.H.: Reasoning about Uncertain
Contexts in Pervasive Computing Environments. In: IEEE Pervasive Computing, Vol.
3 (2), pp. 62–70. IEEE, 2004.
[RJC12] Ramirez, A.J., Jensen, A.C., Cheng, B.H.C.: A Taxonomy of Uncertainty for
Dynamically Adaptive Systems. In: SEAMS 2012, pp. 99–108. IEEE, 2012.
[Se14] Segata, M. et al.: Supporting Platooning Maneuvers through IVC: An Initial Protocol
Analysis for the Join Maneuver. In: WONS 2014, pp. 130–137. IEEE, 2014.
[Sc16] Schaefer, I. et al.: Variant Management and Reuse. In: Advanced Model-Based
Engineering of Embedded Systems – Extensions of the SPES 2020 Methodology, pp.
197–222. Springer, 2016.
[Wa03] Walker, W.E. et al.: Defining Uncertainty: A Conceptual Basis for Uncertainty
Management in Model-Based Decision Support. In: Integrated Assessment, Vol. 4 (1),
pp. 5–17. Swets & Zeitlinger, 2003.
[WS10] Welsh, K., Sawyer, P.: Understanding the Scope of Uncertainty in Dynamically
Adaptive Systems. In: REFSQ 2010, LNCS 6182, pp. 2–16. Springer, 2010.
[Wh09] Whittle, J. et al.: RELAX: Incorporating Uncertainty into the Specification of Self-
Adaptive Systems. In: 17th Int. RE Conference, pp. 79–88. IEEE, 2009.
[Zh16] Zhang, M. et al.: Understanding Uncertainty in Cyber-Physical Systems: A Conceptual
Model. In: ECMFA 2016, LNCS 9764, pp. 247–264. Springer, 2016.
[Zh17a] Zhang, M. et al.: Specifying Uncertainty in Use Case Models in Industrial Settings.
Simula Research Laboratory, Technical Report 2016-15, February 2017.
[Zh17b] Zhang, M. et al.: Uncertainty-Wise Cyber-Physical System Test Modeling. In:
Software & Systems Modeling, Published Online. Springer, 2017.