CyPhERS CPS Methods and Techniques

Transcription

CyPhERS
Cyber-Physical European Roadmap & Strategy
www.cyphers.eu
DELIVERABLE D4.1
CPS Methods and Techniques
Document Version:
Document Status:
Date:
Dissemination:
1.0
Final
February 1, 2014
Public
Project co-funded by the European Union’s Seventh Framework Programme (FP/2007-2013)
Coordination and Support Action
Contract number 611430
Project Start Date: 01 July 2013, Project Duration: 18 months
Project Consortium Information
Participants
Contact
fortiss GmbH (Coordinator)
Guerickestraße 25
80805 München, Germany
María Victoria Cengarle
Phone: +49 89 3603522 29
Email: cengarle@fortiss.org
Kungliga Tekniska högskolan (KTH)
Brinellvagen 8
10044 Stockholm, Sweden
Martin Törngren
Phone: +46 8 7906307
Email: martin@md.kth.se
Université Joseph Fourier Grenoble 1 (UJF)
621, Avenue Centrale, Domaine Universitaire
380410 Grenoble, France
Saddek Bensalem
Phone: +33 0456520371
Email: saddek.bensalem@imag.fr
Università degli Studi di Trento
Via Belenzani 12
38122 Trento, Italy
Roberto Passerone
Phone: +39 0461283971
Email: roberto.passerone@unitn.it
The University of York
Heslington Hall
York YO10 5DD, UK
John McDermid
Phone: +44 1904 325419
Email: john.mcdermid@york.ac.uk
Siemens AG (affiliate partner)
Otto-Hahn-Ring 6
81739 München, Germany
Thomas Runkler
Phone: +49 89 636 40010
Email: thomas.runkler@siemens.com
Authors
Name
Partner
Contact
Université Joseph
Fourier Grenoble 1
+33 0456520371
saddek.bensalem@
imag.fr
María Victoria Cengarle
fortiss GmbH
+49 89 3603522-29
cengarle@fortiss.
org
Roberto Passerone
Università degli
Studi di Trento
+39 0461283971
roberto.passerone@
unitn.it
Alberto
Sangiovanni-Vincentelli
Università degli
Studi di Trento
+39 335218403
alberto@berkeley.
edu
Martin Törngren
Kungliga Tekniska
högskolan
+46 8 7906307
martin@md.kth.se
Responsible Author
Saddek Bensalem
Contributing Authors
CyPhERS – Cyber-Physical European Roadmap & Strategy
Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1 Introduction
2
2 A Science of Cyber-Physical Systems
2.1 Linking Computing to Physical Systems . . . . . . . . . . . . . . . . . .
2.2 Cyber-Physical System Design . . . . . . . . . . . . . . . . . . . . . . .
2.3 The Limits of Understanding and Mastering the Cyber-physical world . .
2.4 The Quest for Mathematically Tractable and Practically Relevant Theory .
4
4
6
7
8
.
.
.
.
.
.
.
.
.
.
.
.
3 Safety and Security
3.1 Technologies for Delivering Requirements: Safety, Security and Privacy Protection
3.1.1 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Directions for Achieving Safety and security . . . . . . . . . . . . . . . . . . .
10
10
10
13
16
16
4 Networked, cooperating systems
4.1 Vision for networked and cooperating systems . . . . . . . . . . .
4.2 Historical evolution and trends . . . . . . . . . . . . . . . . . . .
4.3 Barriers and Challenges for Networking and Cooperative systems
4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
18
18
18
21
23
.
.
.
.
24
24
26
27
28
6 Architecture and Platforms for CPS
6.1 An example of CPS architecture: An Aircraft Electric Power System . . . . . .
6.2 Barriers and Challenges for Architecture and Platforms for CPS . . . . . . . .
31
31
34
5 Human-interaction systems
5.1 Human-Machine Interaction . . . . . . . . . .
5.2 Human Factors . . . . . . . . . . . . . . . . .
5.3 Seamless interaction in intelligent environments
5.4 Shared control . . . . . . . . . . . . . . . . . .
Deliverable D4.1 – Methods and Techniques
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
6.3
6.4
Directions for the design of CPS Architecture and Platforms . . . . . . . . . .
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Engineering for integrating cyber and physical system components
7.1 Abstractions and layered design . . . . . . . . . . . . . . . . . . . . . .
7.2 Model-Based development . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Component-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Virtual integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.7 Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Conclusions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
37
39
40
42
44
44
45
46
47
49
ii
Executive Summary
The framework for Cyber-Physical Systems (CPS) presented in Deliverable D2.1 is further deepened in the present document with respect to the CPS-relevant methods and techniques that are
currently available or already foreseeable. These are systematically identified and structured according to different perspectives: after a motivating introduction, the big challenge is examined
that is posed by the necessary development of a formal and foundational science tailored to the
description of systems that are situated between (and must reconcile models and techniques of)
disciplines of as diverse nature as statistics and psychology—to name just two. Subsequently, a
prominent issue is addressed, namely how to ensure that the novel systems are safe and secure,
with focus also on privacy protection. Next, the interoperability of networked and cooperating
systems is scrutinized. Afterwards the questions related to the interaction between CPS and
human users and operators are dealt with. The following two chapters are of more technical
nature and devoted to, on the one hand, architectures and platforms for, and on the other, the engineering of CPS components. Finally some conclusions are drawn. There will be a follow-on
document where further insights gained particularly via consultations and the organization of an
expert workshop will be collected and organized.
1
1 Introduction
The principal barrier to developing the field of Cyber-Physical Systems (CPS) is the lack of a
theory and of application best practices that comprehend cyber and physical resources in a single unified framework. There are several “disconnects” which need to be addressed to provide
effective means for engineering CPS; in this introduction we focus on the disconnect between
CS and control engineering by way of illustration. Indeed, and as mentioned in [CPS08], one
main culprit is the technical and cultural separation between computer science and control theory. This separation extends to virtually all domains where computers interact with the physical
world. Methods for designing computer systems and physical systems are based on simplifying assumptions about each other that limit the range of systems that we can build. At one
extreme, computer engineers and scientists have largely ignored requirements for physical systems, using abstractions. At the other, control and signal processing theory abstract computers
largely as infallible numerical devices. This simplification ignores many important aspects of
computing, such as increasingly larger timing variance due to caches and energy management
and increasingly higher software error rates caused by complexity. Simplifying assumptions are
also made about communications. Initial designs assume zero-loss, zero-delay communications,
while neither occur in the wireless, low-power, shared, rapidly changing systems used in most
CPS. The viability of future CPS must also address noise in measurements, inaccuracies in actuation, disturbances from the environment, and faults and failures in the computational process
in a coherent, unified framework. This topic will be dealt with in details in Section 2.
Further, the issues of reliability, safety, and security are important in the acceptance and use
of the CPS. Some of the key challenges to be considered include what is needed to cost effectively and rapidly build in and assure safety, dependability, security (which has been largely
ignored in common engineering practice for CPS but which is getting an increasing attention due
to the potential disruptions), and performance of next-generation CPS; how to ensure these systems be fault tolerant and adaptive; and developing the mechanisms and methods for efficiently
upgrading and re-certifying systems. This topic will be addressed in Section 3.1.
The CPS’s of tomorrow will consist of a possibly large number of components that must
cooperate to provide the services that we expect from them. This will imply goal directed, costefficient and effective communication across components, sub-systems, and systems. Such capabilities will be enabled by inter-operability standards, relying on advances in CPS engineering
2
and theory including composability principles, algorithms for distributed decision making, and
techniques for guaranteeing quality of service and negotiation. The new level of inter-operability
will enable cooperative systems to be designed and to form statically or dynamically interconnected groups, while providing desired properties such as performance, security and usability.
This topic will be addressed in Section 4.
Some of the many applications of CPS require tight interaction between the CPS and humans
as, for example, Air Traffic Management systems and semi-autonomous vehicles. The interaction has to come natural for the humans and has to be unambiguous and direct so that the cyber
part of CPS can act promptly. Present interfaces are at best clumsy and need a major overhaul.
To this end, interdisciplinary engineering methods are relevant where non-technical fields such
as psychology and law have to be considered. This topic is going to be discussed in Section 5.
Architecture and platforms are key components of CPS. Indeed, innovative architecture and
platforms are needed to support highly complex and inter-connected CPS. A key consideration
is how to enable development and application of comprehensive architectural frameworks that
include both the physical and cyber elements of CPS. Other issues to be considered include what
new platforms will be needed to effectively extract actionable information from vast amounts of
raw data; and how to provide a robust timing and systems framework to support the real-time
control and synchronization requirements of complex, networked, engineered physical systems.
Advances will also be needed in sensing, control, and wireless communications to enable optimized performance, diagnostics, and prognostics. This topic will be addressed in Section 6.
Finally, while a proper science of CPS will result in models and analysis methods that support the exploration of these issues, their effective implementation requires the development of
efficient engineering processes and design methodologies that can reliably and consistently produce systems that satisfy the desired properties. Of particular importance in the case of CPS is
the integration of the computational infrastructure (the cyber part of the system) with the physical
components and the environment. Key non-functional requirements, such as safety and security,
must also be enforced and guaranteed across the design steps and across the various infrastructures and communication channels employed in the system. These issues will be discussed in
Section 7.
3
2 A Science of Cyber-Physical Systems
The science and engineering of CPS are cross-disciplinary in nature, requiring expertise in computer science, mathematics, statistics, engineering, and the full spectrum of physical sciences
—even extending into the arts such as ethics and psychology. Working across disciplines can
be challenging, as it requires experts with highly diverse backgrounds to communicate on a
common basis.
In this section, we discuss four issues raised by this multi-disciplinary vision for CPS.
1. How CPS system design can be linked to other system design theories and practices?
Establishing links can mutually enrich and cross-fertilize engineering disciplines. Furthermore, this is essential for matching needs for increasing immersion of the cyber-world
in human and physical environments.
2. Is design central to CPS? Today, complex systems are developed in an ad hoc manner
rather than without caring so much about a priori disciplined development. If empiricism
is gaining ground and becoming the dominant doctrine in complex system development,
it will soon hit the wall for trustworthy and cost-effective systems integration.
3. What are the limits of understanding and mastering the cyber-physical world? Awareness of current limitations should allow finding avenues for overcoming them as much as
possible or mitigating their effects.
4. What type of theory is the most adequate for CPS system design? Can mathematical
elegance and practical relevance be reconciled?
2.1 Linking Computing to Physical Systems
Increasing immersion and interaction of computing systems with both physical systems and societal systems, inevitably poses the problem of the very nature of computing and its relationship
to other scientific disciplines. What computing is about? How the interplay between different
types of systems (physical, computing, biological) can be understood and mastered? To what
extent multi-disciplinary systems approaches can contribute to a cross-fertilization and further
development of science and technology?
4
Computing is a scientific discipline in its own right with its own concepts and paradigms. It
deals with problems related to the representation, transformation and transmission of Information. Information is an entity distinct from matter and energy. It is a resource that can be stored,
transformed, transmitted and consumed. It is immaterial but needs media for its representation
by using languages characterized by their syntax and semantics. It should not be confused with
physical information measured as entropy in Information Theory and Physics.
Computing is not merely a branch of Mathematics. As any scientific discipline, it seeks
validation of its theories on mathematical grounds. But mainly, and most importantly, it develops specific theory intended to explain and predict properties of systems that can be tested
experimentally.
The advent of embedded systems brings computing closer to Physics. Linking physical systems and computing systems requires a better understanding of differences and points of contact
between them. Is it possible to define models of computation encompassing quantities such as
physical time, physical memory and energy? Significant differences exist in the approaches and
paradigms adopted by the two disciplines.
Classical physics is primarily based on continuous mathematics while Computing is rooted
in discrete non-invertible Mathematics. It focuses mainly on the discovery of laws governing
physical phenomena while computing systems are human artefacts. Its laws are declarative by
their nature. Physical systems are specified by differential equations involving relations between physical quantities. The essence of many physical phenomena can many times be dealt
with through piece wise linearization. When lumped abstractions are no longer possible, more
complex (partial differential) equations results. A main difference with respect to the digital
world is however the fact that phenomena are local. This reduces the complexity compared
to networked software where a local effect in principle could affect any other connected piece
of software. Computing systems are described in executable formalisms such as programs and
machines. Their behaviour is intrinsically non-deterministic. Non-decidability of their essential
properties implies poor predictability.
Computing enriches our knowledge with theory and models enabling a deeper understanding
of discrete dynamic systems. It proposes a constructive and operational view of the world which
complements the classic declarative approach adopted by Physics.
These differences delimit a gap hard to be filled by computing systems. Consider simply
robustness, which means that the effects of small changes in a system are commensurably small.
Discreteness makes practically impossible this property for existing models of computation.
5
2.2 Cyber-Physical System Design
Design is the process that leads to an artefact meeting given requirements. These comprise functional requirements describing the functionality provided by the system and extra-functional
requirements dealing with the way resources are used for implementation and along the artefact’s lifecycle. Design is a universal concept, a par excellence intellectual activity linking the
immaterial world of concepts to the physical world. It is an essential area of human experience,
expertise and knowledge which deals with our ability to mould our environment so as to satisfy material and spiritual needs. The built world is the result of the accumulation of artefacts
designed by humans.
Design can be decomposed into two phases. The first is the conceptual design, leading from
requirements to a functional/behavioural description, and the second is the embodiment design,
where technologies (digital/physical) are chosen to realize the functionalities. A main concern
is how to meet extra-functional requirements by using available resources cost-effectively.
The design of CPS is hampered by the limited ability to design at a systems-level. There
are many factors impeding system-level design, such as the lack of formalized high fidelity
models for large systems, insufficient ways of measuring performance, and inadequate scientific
foundations.
A key factor is correct-by-construction design. There is great merit in this approach, and
a key aim for the science and engineering of CPS is to see how to extend these principles to
cover the full range of properties of concern for CPS. The principles of correct-by-construction
approaches are at the root of any mature engineering discipline. They allow to reason about the
properties of the designed system incrementally and compositionally along the design process.
They are scalable and do not suffer limitations of correctness-by-checking. Testing may be still
necessary, but its role is to validate the correct-by-construction process rather than to find bugs.
System developers extensively use algorithms, protocols and architectures that have been
proven correct. They also use compilers to get across abstraction levels and translate high-level
languages into (semantically equivalent) object code. All these results and techniques largely
account for our ability to master complexity and develop systems cost-effectively. Nonetheless,
we still lack theory and methods for combining them in principled and disciplined fully correctby-construction flows.
For designing CPS we need a methodology to ensure correctness-by construction gradually
throughout the design process by acting in two different directions:
• Horizontally, within a design step, by providing rules for enforcing global properties of
composite components (horizontal correctness) while preserving essential properties of
atomic components;
6
• Vertically, between design steps to guarantee that, if some property is established at some
step, then it will be preserved at all subsequent step (vertical correctness).
Scientific and technical challenges to achieving this approach include a lack of mathematical and
system science foundations, formalized metrics, evaluation techniques, and methods for dealing
with cross-cutting properties in the design space. Furthering the mathematical methodology
for design space exploration is critical for allowing a principled approach to design complex
architectures that are modular.
2.3 The Limits of Understanding and Mastering the
Cyber-physical world
Abstraction hierarchies are a human invention intended to assist people in mastering the complexity of systems by ignoring unnecessary details. They determine successive levels of granularity of observation at which system properties can be studied. Theory should allow predicting
how properties at some level are reflected upstream or downstream in the hierarchy. In addition
to the reflected properties, it should also allow to determine new emergent properties.
Within the CPS globe, it is essential to develop theory methods and tools for climbing up
and down the different level of abstraction. How energy efficiency can influence the way we are
designing? Which models most adequately feature system behaviour at each abstraction level?
How models and their properties, at different abstraction levels, can be related through wellfounded abstraction relations? These problems will probably remain open for decades. Their
answers will largely determine our ability to master the cyber-physical world.
Discreteness of computation and uncertainty seriously compromise our ability to guarantee
correctness. Traditional engineering amply relies on robust system behaviour: small changes of
parameters within an interval of values have commensurable effects. Due to discreteness of computation, qualitative properties are not robust. Safety or security properties may be jeopardized
by the slightest physical devices or software modification. Even quantitative properties such as
performance, are not robust due to non-determinism and uncertainty, e.g., timing anomalies.
In many systems, such as the national power grid and traffic control systems, both the plants
and the computers for monitoring and control are physically distributed. In such systems, the
dynamics of the distributed computing platform and the distributed plant interact in ways that
determine the overall operation of the system, but are as yet poorly understood. It is not clear we
have sufficient paradigms for making distributed control, sensing, and communication, in safety
and time-critical CPS.
Finally, formal methods for determining reliability are lacking for most CPS and need to be
developed. Effective characterization and quantification of reliability will ensure that systems
7
are robust and resilient, and provide better understanding of potential risks to system operation. For quantitative properties, we need a deeper understanding of the interplay between their
predictability and uncertainty.
2.4 The Quest for Mathematically Tractable and Practically
Relevant Theory
The proper goal of theory in any field is to make models that accurately describe real systems.
Models can be used to explain phenomena and predict system behaviour. They should help
system builders do their jobs better.
Theoretical research has a predilection for mathematically clean theoretical frameworks, no
matter how relevant they can be. Many theoretical frameworks and results are “low level” have
no point of contact with real computing. A quite different attitude is adopted by practically oriented research. Existing frameworks for programming or modelling real systems are constructed
in an ad hoc manner. They are obtained by putting together a large number of semantically unrelated constructs and primitives. It is practically impossible to get any rigorous formalization and
build any useful theory for such frameworks. Is it possible to find a mathematically elegant and
still practicable theoretical framework for CPS? The solution is not simply to juxtapose the cyber
and physical aspects. It requires their tight integration within a new mathematical foundation
that spans both perspectives.
Today, building formalized, high fidelity models using mathematically based, formalized
modelling languages is expensive, time consuming, and lacking tools and methods for large
heterogeneous systems such as CPS. There exist different tools and approaches for building
components and composing them. There are a large number of models, languages, and notations
that exist, however, many of which are most appropriate only for particular problem or areas.
No complete solutions exist for CPS.
What is needed for CPS?
1. For the development of reliable, safe, and secure CPS we need:
• a structural framework for high fidelity models,
• an universal definition for large heterogeneous systems,
• a cost-effective verification and validation of complex CPS that encompasses emergent behaviour of composed systems (be this behaviour desirable or not), and
• metrics and tools for CPS verification and validation.
8
2. CPS can be highly connected and integrated in multiple ways, even across business operations and domain boundaries. Achieving effectively networked, cooperating, and humaninteractive systems will be an integral factor in the adoption of such systems in the future.
There is a need to:
• Model human strengths and weaknesses as well as corresponding machine strengths
and weaknesses. Such models will enable a more natural, seamless interaction between humans and CPS and will help to manage risks and safety.
• Characterize and quantify the system uncertainty in order to understand the implications of the inputs and their variability on system operation.
• Have an interconnected and interoperable shared development infrastructure
3. While CPS has become part of contemporary applications from healthcare to the power
grid, major improvements in functionality and the ability to navigate complex situations
will require significant advances and developments in CPS technology. For these we need
to have:
• An abstraction infrastructure to bridge digital and physical system components
• Testing and Certification of Compositional Systems
• Cost-effective, secure system design, analysis and construction.
4. Innovative architecture and platforms are needed to support highly complex and interconnected CPS. A key consideration is how to enable development and application of comprehensive architectural frameworks that include both the physical and cyber elements of
CPS. There is a need to:
• A systematic structured design and process Integration
• Ensure the correctness of CPS systems in an ever-complex, uncertain environment
• Have a trustworthy, holistic infrastructure for the Evaluation of CPS
• To manage the role of time in architecture design
9
3 Safety and Security
This chapter is devoted to the delicate matters of Safety and Security, including privacy protection. These issues are key for the success and acceptance of the novel technologies and systems.
They are, in the following, approached from two sides: their definition and today’s standards,
and the directions leading to their future management.
3.1 Technologies for Delivering Requirements: Safety,
Security and Privacy Protection
The issues of reliability, safety, and security are important in the acceptance and use of the CPS.
Some of the key challenges to be considered include what is needed to cost effectively and
rapidly build in and assure safety, dependability, security, and performance of next-generation
CPS; how to ensure these systems become fault tolerant and adaptive; and developing the mechanisms and methods for efficiently upgrading and re-certifying systems. Dependability is usually
taken to refer to a combination of traditional safety and security features such as functional
safety [ALRL04], reliability, availability, confidentiality, integrity and maintainability features.
In this section, we will discuss technologies for implementing all these system features.
3.1.1 Safety
A system’s safety is defined as the absence of unacceptable risks resulting from threats posed by
the system itself. As described above, the key requirements for safety are the system’s functional
safety and reliability [ISO10]. A general definition of reliability, which is endorsed by the
definition proposed in [Mus04], is the probability of a system operating without error for a given
time and in a given environment. As well as maturity and fault tolerance (i.e., low fault rates
and the ability to keep working when a fault occurs), DIN ISO 9126 demands two additional
features: robustness, or the ability to guarantee basic functionality in the event of a fault, and
recoverability, or the ability to easily restore functionality after a fault has occurred. Since
robustness and fault tolerance are also generally regarded as typical features of functional safety,
current safety standards such as the IEC61508 families address both aspects in their call for an
integrated approach to the development of safe systems.
10
Reliable multicore processors: The parallel operation at the hardware level enabled by reliable
multicore processors, i.e., processors with several processing cores, makes it possible to implement simultaneous safety mechanisms, e.g., through the redundant design of safety functions,
parallel operating status monitoring or full isolation of different system-critical functions. The
same applies to mechanisms for enabling energy-efficient operation involving, e.g., turning processing cores on and off depending on the current operating status or performance requirements.
Safety cannot be guaranteed without hardware redundancy. However, CPS-type systems are
characterized by a high number of controllers that may not always be very well connected to
each other. Affordable, easily scalable, redundant hardware such as multicore systems is therefore essential. Current parallel processor technology is not able to provide the necessary redundancy to cope with faults. In particular, current multicore architectures are confined to a single
substrate, i.e., a single slice of silicon that houses a circuit. This means that they are unable
to achieve more than the most basic Level 1 hardware fault tolerance. Furthermore, although
current platforms have redundant processing cores, the same is not true of the key components
of each input and output device, bus and memory management unit, meaning that the necessary
isolation mechanisms are lacking.
Component description and testing at run-time: Technologies for describing component safety
make it possible to test key guaranteed characteristics such as maturity –e.g., by establishing the
number of errors still present in the system–, permitted application contexts or operating status
when components are integrated at run-time –i.e., after delivery and installation– and in the real,
functional operating environment. These description technologies enable the system surrounding a component to ensure that it is integrated reliably. Component descriptions thus constitute
binding contracts for the components in terms of both expectations and performance. This is
especially important because parts of CPS may have to operate in undefined or partially defined
contexts that were not fully known at the time when the system was designed or that changed
at some point after it was designed. Current approaches to describing and testing component
properties at run-time tend to be confined to the components’ syntactic properties such as the
number and type of interface elements or simple functional properties.
Global platforms with high-order integrated safety mechanisms: Platforms with high-order integrated safety mechanisms can provide safety@runtime services that contribute to safety by
enabling straightforward implementation of application-specific safety requirements. This is
usually done by using generic mechanisms as system functions. These include mechanisms for
monitoring operating status –e.g., via monitoring functions– that are derived from protection
goals and consequently work towards achieving these goals. They also include mechanisms
for safeguarding operating status such as automatic function replication, including the ability
to switch between replicated functions. Importantly, these are cross-device platforms that thus
11
enable topology-independent operation of safety functions. As CPS grow, so does the number of
software and hardware components on a platform that can provide functions. At the same time,
however, extra safety functions also become necessary. Scalable mechanisms for fulfilling safety
requirements are therefore necessary. It will be possible to implement scalable, dependable systems by making generic and user-friendly safety services available in platforms. Most current
platforms provide very few of the safety mechanisms required to implement safety functions.
They are largely confined to hardware-oriented mechanisms such as memory integrity and fault
containment or hardware-related mechanisms such as virtualization geared towards separating
functions and services in time and space. Higher-order services are not normally provided as
standard.
Wider development and safety standards: Wider development and safety standards will need to
go beyond the concepts of a system typically used by product liability law. Product liability
law deals with liability issues for systems that have been created by manufacturers for a defined
purpose until such a time as the system is decommissioned. In particular, these standards and
technologies support the different life cycles of the system’s parts, shared responsibilities and especially legal liability, and the deployment of systems and components in completely or partially
undefined contexts. CPS generally involve interactions between components made by different
manufacturers and with different life cycles. It is important for regulations and standards to take
this fact into account in order to enable the full range of technologies and processes required to
make the use of CPS-type systems sufficiently dependable. Current safety standards are predominantly geared towards closed systems with limited user groups, clearly-defined responsibilities
and restricted contexts of use. They thus largely fail to recognize that these restrictions are unrealistic for CPS-type systems. Scalable safety concepts and theories: Scalable safety concepts
and theories are capable of providing a single overview of large, extremely heterogeneous subsystems with very different safety goals. They enable an integrated approach to analysing the
safety of numerous interacting sub-systems. These concepts and theories are scalable insofar
as they enable the outputs of individual sub-systems to be scaled up to the level of CPS-type
systems. In particular, these theories and concepts support the modular and hierarchical composition of safety goals. Since CPS generally involve a combination of different sub-systems
whose safety goals may not be closely coordinated, it is important to be able to map, investigate
and predict the interactions between these sub-systems in order to ensure the dependability of
the CPS-type system. Current methods for assessing system safety are mostly based on closed
systems. Existing approaches largely overlook the fact that the sub-systems in CPS interact with
each other in order to accomplish a common safety goal. They also fail to address the fact that
sub-systems with conflicting safety goals still interact with each other.
12
3.1.2 Security
Security is a basic requirement for CPS. The technologies used will need to employ measures
that provide protection against attacks. It will be particularly important to guarantee secure communication, since this will often occur via wireless communication interfaces. This will require
technologies for ensuring that communication only takes place with authenticated and authorized partners. In addition, it will be necessary to guarantee the integrity and confidentiality of
the data being transmitted. In other words, these data will need to be protected against tampering
and eavesdropping. It will also be essential to guarantee the availability of communication. This
is especially important when data need to be up-to-date and guaranteed real-time requirements
have to be fulfilled. Moreover, when data that can be traced back to individuals are being processed, it will be necessary to employ technologies that protect the privacy of CPS users. In the
smart mobility scenario, for example, it is important to ensure that profiles of users’ movements
cannot be drawn up; in particular, uncontrolled information flows need to be prevented.
In addition to ensuring secure communication, it is also necessary to provide protection
for the various systems, devices and components that form part of the system, since these are
often deployed in public places and are therefore highly susceptible to attacks involving physical tampering. Consequently, the data stored on these systems need to be protected against
tampering, unauthorized access and destruction. This applies both to system data such as the
operating system and to stored data such as measurements or the cryptographic keys used to
enable secure communication. CPS often involve interactions between unknown communication partners, some of who may harbour malicious intentions. As a result, technologies will be
needed for assessing communication partners’ trustworthiness. Security needs to be addressed
not only during the development stage of CPS but also once they are up and running. This will
require engineering capabilities that enable implementation of security concepts for ensuring
that the systems are both Secure by Design and Secure during Operation. Delivery of these capabilities will require security technologies that use a variety of different approaches. The first
approach is attack prevention. Encryption, for example, can be used to prevent eavesdropping
as long as hackers do not have access to the relevant cryptographic keys. Meanwhile, attack
detection technology can be used in situations where it is not possible to prevent attacks, as well
as to assess the effectiveness of attack prevention technologies. It can also trigger appropriate
responses. These technologies include Intrusion Detection Systems that detect suspicious behaviour by communication partners and attestation processes capable of instantly recognizing
when a system has been tampered with. The third approach is recovery. This includes technologies such as self-healing, as well as the ability to tolerate attacks up to a reasonable point. The
specific technologies required are described below.
Efficient and lightweight cryptographic procedures and protocols: Efficient and lightweight
13
cryptographic procedures and protocols that are tailored to the resource limitations of the system
in question can be used to enable secure communication and thus meet protection goals such as
authenticity, confidentiality and integrity. These procedures and protocols must be adapted to the
properties and requirements of the relevant CPS components, e.g., limitations on the available
resources. A further challenge is that the long service life of these components will require procedures, protocols and cryptographic keys that can either be replaced or that will remain secure
throughout the duration of a lengthy service life.
Component protection through dedicated security hardware: CPS components are highly susceptible to attacks involving physical tampering. Effective methods are needed for protecting
the relevant systems and the data that they hold against tampering and unauthorised access.
Specialised Hardware Security Modules (HSMs) offer one potential solution that is particularly
attractive to CPS because of its affordability. HSMs provide secure memory and secure execution environments for security-critical operations. Moreover, they often include additional
mechanisms for enabling detection of tampering with the systems’ own system software. These
mechanisms may also be used as the basis for assessing a system’s trustworthiness (see below).
For many CPS communication scenarios, it would be desirable to develop specialised Machineto-Machine (M2M) modules with integrated HSMs or adapt existing modules to the forms of
communication used by CPS. These modules would then provide the basis for enabling secure
communication between individual CPS components. The majority of HSMs currently in use,
for example the Trusted Platform Module (TPM), are deployed in conventional systems such as
desktop PCs. If HSMs are to be used with CPS, they will either need to be adapted to the specific
characteristics of CPS or completely new modules will have to be developed. For example, it
will be necessary to support the virtualisation technologies described below in as resource- and
cost-efficient a manner as possible.
Secure execution environments: Secure execution environments isolate operations from each
other in order to prevent any interaction between them. It is necessary to do this because several
different operations with different security requirements are often carried out on CPS components. Secure execution environments need to be adapted to the relevant CPS. For example, it
will be necessary to develop virtualisation technologies that can be deployed in embedded systems. It is also especially important to ensure that these technologies are themselves protected
against tampering. This will require secure boot processes and operating systems that use the
appropriate HSMs. Middleware can also be used to provide applications with security services
in a transparent manner.
Processes for establishing trustworthiness: Processes for establishing the trustworthiness of
CPS components make it possible to check whether their behaviour matches their specifications.
Since CPS are employed in insecure environments, they are susceptible to being compromised
14
by hackers. Processes for establishing trustworthiness make it possible to detect when they have
been compromised. One approach to establishing trustworthiness is the use of behaviour-based
systems that have been adapted to the requirements of CPS, for example machine-learning based
anomaly detection supplemented by a reputation system. This approach involves monitoring
the behaviour of the system in order to detect and assess any changes or potentially malicious
behaviour. An alternative strategy involves lightweight attestation processes that immediately
detect when a device has been tampered with. The advantage of these processes is that they enable the system software’s status to be checked rather than being based on unreliable monitoring
of the system’s behaviour. Most attestation technologies are based on dedicated HSMs which
act as trust anchors. Attestation processes for CPS will need to be significantly more efficient
than those used in conventional application areas. They will also need to be adapted to the new
HSMs and, where relevant, support virtualization.
Security engineering for CPS: Security engineering involves the design and development of
comprehensive security architectures and processes. Security engineering must be incorporated
into the development of CPS right from the outset in order to ensure that protection against
attacks forms an inherent part of the system. It is important to do this because it is often not
possible or not effective to add on security measures after the system has been built. Current
security engineering processes are focused on conventional computer systems and have yet to
be adapted to the requirements of CPS. The development of CPS technologies will require secure hardware/software co-design as well as new best practices and standards for CPS security
engineering. Security management: Security management enables security to be maintained
throughout the time during which CPS are operating and to be adapted to new situations if necessary. In order to ensure secure operation, security management needs to take into account the
lengthy service life and life cycles of CPS. This will require security architectures to be developed in a way that allows processes and algorithms to be replaced if they prove to be insecure.
The ability to replace cryptographic keys will also be necessary in case they are compromised or
become insecure because of inadequate key lengths. Moreover, it will be necessary to identify
keys as being invalid if a user or sub-system leaves a CPS.
Test and analysis methods: It will be necessary to develop new test and analysis methods that
take into account the specific features of CPS. Security test and analysis methods make it possible to check what level of security has been attained and whether the security feature requirements have been met. The complexity of CPS often makes it difficult if not impossible to provide
formal proof of security features’ effectiveness. In many cases, the only manageable test and
analysis methods are those that check the system’s security with regard to known and, to a limited extent, unknown attacks.
15
3.1.3 Privacy
Privacy protection is one of the factors that will be key to the acceptance of CPS. It is not only
necessary for the technological systems to meet the safety and security requirements described
in the previous sections. Rather, the design of CPS should also take privacy considerations into
account right from the outset (Privacy by Design [Cav09]). This concept is well-established in
the global data protection community and involves the inclusion of privacy requirements in all
phases of a system’s life cycle, from its conception and design to its implementation, configuration and continued development. The goal, wherever possible, is to prevent any threats to
privacy or at least to keep them to a bare minimum and to make sure that any remaining threats
are clearly identified. Usually, when a system is designed, its specific privacy requirements are
taken from the relevant legislation for its area of application. However, since CPS constantly
adapt to new requirements and cooperate with other systems, it is no longer possible to precisely
define their area of application. Consequently, it is desirable to adopt an approach similar to
the tried-and-tested processes used in the fields of information security and IT baseline protection [BSI12], whereby the appropriate measures for meeting the relevant privacy requirements
are selected based on the protection needs identified for the information being processed and the
technological systems in question. The three traditional information security protection goals
are confidentiality, integrity and availability. These are supplemented by the three additional
privacy protection goals of transparency, intervenability and unlinkability [RP09, RB11];
3.2 Directions for Achieving Safety and security
The key scientific and theoretical challenges for CPS is the topics of security, Privacy and Safety:
• CPS raises new issues in topics of security and privacy because physical systems reveal
information, there are limits on what information can be hidden, and new kinds of physical and cyber-physical attacks are possible. New science and theory is needed for CPS on
these topics to include design principles for resilient CPS, threat analysis vs. hazard analysis, theories of cyber-physical inter-dependence, and examination of the possible role of
gaming of different layers of the system.
CPS are also susceptible to additional security attacks beyond those found in cyber systems. This includes jamming the communications, physical tampering, overhearing and
many more.
In CPS, physical and cyber elements motivate different models of trust so that erroneous
behaviour is detected and human operators maintain appropriate scepticism during system
operation. New science and theory is needed to define cyber-physical inter-confidence and
16
trust maps, CPS context dependent trust models, and ground truth detection capabilities
(based, e.g., on real-world physical limits).
• We need to develop new theories of correctness for CPS that allow new correct-by-construction approaches: property preserving transformation of existing and new systems,
CPS requirements through specification through design through implementation, correctness validated by testing assumptions (rather than by attempting to test everything). Correct-by-construction approaches are at the root of any mature engineering discipline. They
allow to reason about the properties of the designed system incrementally and compositionally along the design process. They are scalable and do not suffer limitations of
correctness-by-checking. Testing may be still necessary, but its role is to validate the
correct-by-construction process rather than to find bugs.
System developers extensively use algorithms, protocols and architectures that have been
proven correct. They also use compilers to get across abstraction levels and translate
high-level languages into (semantically equivalent) object code. All these results and
techniques largely account for our ability to master complexity and develop systems costeffectively. Nonetheless, we still lack theory and methods for combining them in principled and disciplined fully correct-by-construction flows.
We also need methods for reasoning about the co-stability of cyber and physical domain
features: degrees of freedom in physical design, degrees of freedom in cyber design, and
coupling of cyber and physical design assumptions. Verification of these properties will be
particularly challenging for open systems and systems based on wireless communications.
17
4 Networked, cooperating systems
The present chapter deals with the indispensable prerequisite for the dynamic and spontaneous
interaction, integration as well as loose collaboration of dissimilar, heterogeneous systems that
moreover are possibly far apart from each other. Firstly, a vision is presented that relates with
foresighted capabilities in different realms. A bridge is built then between the evolution up to
date and the trends leading to the vision. Afterwards challenges and barriers are discussed that
must be addressed in order to make the vision a reality. A discussion closes this chapter.
4.1 Vision for networked and cooperating systems
The CPS’s of tomorrow will provide new levels of interoperability that will enable cooperative
systems to be designed and to form statically or dynamically, while providing desired properties
such as end to end performance, security and evolvability. Such capabilities will utilize new
networking and distributed systems technologies and standards, that need to encompass heterogeneous communication requirements, and techniques for guaranteeing quality of service and
negotiation.
The above vision is in line with visions from the telecommunication domain, for example
referring to the vision of Ericsson of 50 billions of connected devices (from the 7 billion of
connected cell phone customers today) and with respect to expectations for 5G to meet requirements for future CPS applications such as the smart grid and regional transportation network;
see [OBH+ 13]. The vision is also in line with research visions towards ubiquitous “swarm
interoperability”. Swarm interoperability relies on novel platform abstractions and communication interoperability to enable efficient sharing of resources (sensing/actuation, networking,
computing, storage) among many applications1 .
4.2 Historical evolution and trends
To illustrate the evolution of networking, consider a modern machine (e.g., a car, an aircraft or
an industrial robot). Such a machine will today contain a set of networked embedded comput1
For further elaboration, see the vision for the Swarm Lab at UC Berkeley at http://swarmlab.eecs.
berkeley.edu/swarm-history .
18
ers, often partitioned into sub-networks depending on the communication nature, e.g., real-time
and safety critical communication for propulsion. This distributed embedded system will in
turn have gateways for external communication, e.g., for the purposes of diagnostics and software upgrades – mainly used for temporary connections. Considering a vehicle it is also likely
to contain a navigator, which may actually correspond to a cellular phone or to a specialized
computational device, in both case with GPS and cellular network communication.
The communication capabilities present in such a modern machine illustrate a diverse set
of communication needs and that communication technologies have been developed in various
CPS related domains of which key examples include the following:
• Machine and various automation-related local area networks for sensing and control. Typical examples include CAN, LIN and FLEXRAY from the automotive domain, MIL1553
and various ARINC standards in the aerospace domain, and Modbus and Profibus in automation related networks in process and manufacturing control. These networks are typically developed for short but latency sensitive messages. Networks for process control
were typically built to function for distributed I/O systems, where a master would poll
sensor/actuator nodes. Examples from the domain of automation related networks include
BACnet and LonWorks. These networks were typically built based on OSI-like communication.
• Ethernet and LANs. Ethernet, with TCP/IP, provided the basis local area networks. Since
then the technology has been evolving and been adopted in many domains including in
CPS applications.
• Short range wireless networks. WLAN has gained wide acceptance. In addition, there are
other radio technologies that target various consumer or industrial applications such as
Bluetooth, ZigBee and NFC. IEEE 802.11p is an example of a recent WLAN derivative
for direct inter-vehicle communication (e.g., between cars, buses or trucks – so called
V2V) or between vehicles and fixed infrastructure (so called V2I).
• Telecommunication related technologies. Telecom standards such as GSM, 3G and HSPA
have evolved rapidly to provide increasing bandwidth, coverage for mobile systems, and
support beyond telephone conversation to data transfer.
• GPS (and Galileo). The Global Positioning System (GPS) needs to be included in this list
because of its relevance for CPS. GPS is a satellite based navigation system that provides
location and time information.
A common trait in the evolution of CPS, is that products and systems are increasingly utilizing not only domain specific communication technologies (such as those exemplified in the first
19
bullet), but also technologies from the remaining four bullets. This common trait is found in all
application domains of CPS, be it in manufacturing, smart houses or the electrical grid. Continuing with the modern machine example above, the car of tomorrow will apart from vehicle
internal communication, also encompass integrated gateways for V2V and V2I communication,
GPS, and some form of telecommunication as well as WLAN. The vehicle may itself also constitute a mobile base station, supporting networking not only for the sake of the car, but also for
other users.
In the evolution of networking, we clearly see that the networking capabilities pave way for a
growing scope of CPS, towards systems of systems. We moreover discern the following trends:
• Networking and Collaboration in new domains. The availability of low-cost and reliable
networking provides new opportunities in all kinds of application domains. Browsing
through new standards, conferences, associations, companies etc. will for example highlight areas such as Wearable and Implantable Body Sensor Networks (BSN conference
series), the Medical device plug and play standard (MDPnP), machine to machine communication, and Robot-human collaboration standards.2 .
• Networking across traditional domains/systems/stakeholders. A good example of such
networking “across systems” is provided by V2V and V2I communication protocols as
standardized for cars. This type of cross system communication provides a basis for entirely new applications such as for example vehicle platoons and sophisticated vehicle
guidance through interactions with the infrastructure and humans. As opposed to traditional “in-machine” networks, such communication implies that new partnerships and
business models will be required since the resulting systems of systems go beyond traditional stakeholders.
• Heterogeneous protocols with some technical convergence. The variety of domains and
requirements, have led to a proliferation of communication technologies as illustrated in
the previous section. Heterogeneity is like to remain not only because of legacy but also
simply because of the heterogeneity of requirements. However, some convergence or
dominant technologies are emerging as exemplified by http/REST-ful protocols, Ethernet
and WLAN. The visions for 5G also (at least) point in this direction.
• Towards open systems with automatic/dynamic configuration. Networking provides a
large potential for including many new features, thus driving the integration of networking
technology (wired as well as wireless) into commercial as well as consumer products.
2
For example, the new ANSI/RIA R15.06-2012 standard, now harmonized with the international ISO 10218:2011
robot safety standard, addresses safe human and robot collaboration
20
Dynamic (or re-) configurability is driven by the ability to benefit from already deployed
(and networked) resources, by utilizing their information and/or services.
• The evolution of networking is reflected by middleware standards and software, meeting
the needs for decoupling software from hardware, and providing the basis for effective
management of distributed applications. Just as for communication protocols, middlewares are emerging essentially per domain, for example with Orocos in the Robotics domain3 , AUTOSAR in automotive4 and OMG DDS for larger scale distributed real-time
systems5 .
4.3 Barriers and Challenges for Networking and Cooperative
systems
The introduction of increasingly mature and capable communication technologies provides a
number of interesting opportunities. There are however a number of barriers that prevent the full
exploitation of these opportunities. In the following we discuss such barriers and challenges.
• Quality concerns and architecture. Increased levels of communication provide more open
systems in which security becomes a major concern. Security relates closely to privacy,
which as a concern goes beyond technology considerations. Security in turn may affect
most other system qualities. Wireless communication is subject to disturbances that may
jeopardize their availability. Availability also requires proper energy management, especially for devices required to operate for a long time and without battery replacement or
energy replenishment. In striving for increasingly flexible and configurable systems, there
is a trade-off w.r.t. system complexity. The long or relatively long life-time, and technology evolution of products provide challenges for developers. Compare for example with
the automotive domain and the speed with which consumer electronics and communication is evolving. Finally, future CPS needs to be able to scale, imposing requirement on the
communication technologies, algorithms and architectures. Architecting future CPS thus
becomes critically important. The increasing level of communication will affect “system
internal architecture” – e.g., in terms of its modularization, but also require architecting at
the system of system level.
• Technical challenges in dealing with reconfigurable distributed systems. There are a variety of distributed systems issues and techniques that need attention including algorithms
3
Open Robot Control Software, see http://www.orocos.org .
AUTmotive Open System ARchitecture, see http://www.autosar.org .
5
Data Distribution Service Portal, see http://portals.omg.org/dds/ .
4
21
for distributed decision making, quality of service, synchronization, localization, dependable operation in spite of faults and attacks, etc. Cooperative systems, in which independent systems without previously signed agreements are to interact, need mechanisms for
negotiation the terms of cooperation at run-time. Communication protocols need further
work to satisfy the various quality concerns and technical challenges. For example, existing wide area mobile as well as wireless communication have been mainly designed for
human-centric mobile-broadband applications. As a consequence, they have limitations
for example with respect to the variety of application requirements for future CPS and
also need to provide efficiency and scalability considering the expected drastic increase
in traffic and number of connected systems. A modern CPS will also need to deal with a
variety of communication modalities and technologies, for example, using and switching
between WiFi, GPRS/HsxPA/LTE as appropriate to enhance availability and efficiency of
services. Context awareness, such as location, may be important in choosing the right
modality and communication medium.
• Multi-domain and stakeholder aspects. The fragmentation across domains has prevented
standardized interfaces and cost-efficiency. Domain specific technologies range from
communication protocols to middleware. The properties and suitability of the technologies rests heavily on domain specific application assumptions and requirements, thus hampering cross-domain reuse and harmonization. Nevertheless, the application drivers for
integration are slowly paving way for harmonization. When forming systems of systems,
organizations need to develop business models and logic across traditional domains, taking aspects such as ownership, responsibility and liability into account. Existing standards
and legislation may also need evolution in order not to hamper such developments; this is
for example the case for cooperative and safety critical vehicular applications.
• Interoperability standards. Interoperability standards for future communication systems
have to be defined at the right levels, and need to consider technology, syntax, semantics,
and architectural aspects. Networking leads to distributed systems, in which artificial
complexity can be reduced if composability can be guaranteed by the system architecture
including networking.
• Ease of use and lifecycle management. Systems and devices that are able to communicate
will need some level of configuration and management in order to perform their work in a
collaborative fashion. Given the large number of such systems, manual configuration and
maintenance will no longer be cost-efficient, and thus there will be a need for automating
some of these functionalities.
• Technology adoption. Adopting networking technologies is challenging especially in new
22
CPS application domains with little experiences of such technologies. Adoption also becomes challenging when cross-domain applications are created. Sufficient competence
and management may not be present. In a survey among 126 SME’s as part of Agenda
CPS, [GBC+ 12], it was identified that adoption challenges typically refer to system aspects such as safety, security, adaptability, methodology, rather than the communication
technologies per se.
4.4 Discussion
Business drivers (top down) as well as new networking technology pave the way for new networking related services, products and standards.
While technologies are slowly converging, many types of technologies are likely to remain
for the foreseeable future. Cross-domain applications will pave way for new applications and
are likely to increase the pace of convergence. Most interestingly, cross-domain applications
will typically create systems of systems, posing a large number of technical distributed systems
challenges as well as non-technical challenges related to business, standardization and legislation.
Achieving interoperability holds the key for grasping synergies arising from networking.
Achieving interoperability is however a challenging multidimensional endeavour encompassing
architecture, algorithms, standardization, business and management.
The large diversity of use cases and requirements, and the heterogeneity of CPS’s, will require the development of new paradigms, engineering techniques and support tools for developing the collaborative CPS’s of tomorrow. These paradigms need to consider a number of
distributed systems aspects, encompassing dynamic configuration, quality of service, efficiency
in terms of energy, resource usage and cost. Systems engineering, architecting and collaboration
among industrial domains and related disciplines, will be important for a successful transitioning
into the fully networked society.
The diversity of communication technologies reflects the diversity of requirements, but also
the fragmentation among industrial domains. There is a need to create multidisciplinary and
multi-domain initiatives to overcome the current fragmentation in academia, across industrial
domains, and between academia and industry. Finally, education in this area is of paramount
importance to pave the way for future sustainable CPS.
23
5 Human-interaction systems
CPS have the potential to be of help for solving some challenges our society is facing such as care
provision for the elderly as well as enabling handicapped people an independent life. There are
a number of unresolved issues regarding human-computer interaction, which are decisive for the
acceptance of CPS, for example concerning individual freedom, governance and fairness in systems with distributed and shared control. As a consequence, a number of technologies need be
upgraded, particularly integrated architectures and integrated models of Human-Machine Interaction (HMI) and Cooperation (HMC). To this end, interdisciplinary (or rather transdisciplinary)
engineering methods are imperative, as well as the relevant competencies for deploying and
operating these technologies, so that they are properly used and the associated non-functional
requirements are also met. In particular, holistic models for HMI and HMC are necessary, and
the devised HMI needs be appropriate and widely accepted. In the following sections we justify
these claims.
5.1 Human-Machine Interaction
The evolution of today’s systems in the direction of the envisioned CPS, signals an increasing
openness of systems, that are intelligent and (partially) autonomous networked. This calls for
an adaption and, moreover, new forms of HMI.
CPS are expected to possess a (series of) dedicated, multi-modal HMI. Furthermore, they
are supposed to provide their services
• largely location-independent,
• yet context-specific (context aware),
• adapted to the demands associated to the situation of the application,
• partially autonomously,
• partially automatically,
• multifunctional as well as
24
• networked and distributed for the individual user and stakeholder.
In this context, the human can be considered as (a) a user, as usual, (b) a “requirement” in the
sense of ergonomics, that their acceptance is pivotal for success, etc., (c) a source of disturbance,
be it because the user refuses the use of technology (and is customarily called a “dropout”), or
attacks the integrity of a CPS, etc., and (d) “enhanced” by CPS, as, e.g., in prosthetics. And,
regarding liability among others, a debate is imperative that clarifies governance as well as normative and regulative aspects, and determines the authority of humans on CPS and vice versa. It
is well-known the accident of the Lufthansa flight from Frankfurt, Germany, to Warsaw, Poland,
that on September 14th, 1993, in which the plane overran the runway due to, among other things,
the braking system not activated since the wheels were not turning although the aircraft was already on the ground, and this because of an aquaplaning effect. That is, the software refused to
obey the pilot’s commands; see [CAA94].
For the future competitiveness of the European manufacturing industry, automation and industrial IT are key technologies of the coming years. Especially companies in this sector will
most probably be affected by the move towards CPS. The main product groups of this industry include sensors, actuators, fieldbus systems, control systems as, e.g., Programmable Logic
Controllers (PLC), Numerical Control (NC) and robot control, products with human-machine
interfaces as, e.g., SCADA systems, and basic electrical products such as drives or regulators.
In general, when modelling and developing intelligent systems, terms such as knowledge,
cognition, learning, and handling, can be used for both the actions of persons and the ones of
machines (although it cannot be spoken of human behaviour of autonomously handling machines such as robots or software-bots on the Internet). In the context of CPS scenarios and their
analysis, however, the use, development and limits of technologies are in the foreground; for
example, multi-agent systems, ontologies, pattern recognition, machine learning or planning in
robotics. This also applies to the issue of HMI. In particular, in Computer Science, in cognitive Psychology and the Natural Sciences, there is a long tradition of mutual benefit regarding
explanation of each other discipline and their modelling as, for instance, the paradigm of information processing in Psychology, and new concepts from the latest findings in Biology and
Neuroscience for sensor technologies.
The Internet transformed how and where information is stored and accessed, the way people
interact and communicate with one another, including, e.g., how products are bought and sold,
services provided, etc. In a similar fashion, CPS transform how users interact with and control
the surrounding physical world. Those systems are expected to operate dependably, safely, securely, efficiently and in real-time (the list is not exhaustive). A scientific and engineering CPS
discipline should advance the conceptualization and realization of future societal-scale systems,
supported by an analysis of the interactions between engineered structures, information process-
25
ing, humans and the physical world. In particular, the engineering of these novel systems must
take into account, among others, the availability and the constraints associated not only with
their cyber and/or physical components, but also with the human operators; see [RLSS10].
Note that the operator not necessarily is a highly trained engineer. The CPS vision encompasses increased support and care of the aging population. The infrastructure put at disposal of
patients with age-related, chronic diseases can be substantially improved by means of CPS, so
that the elderly can comfortably stay at home longer.
In the automotive domain, and due to the complexity of the environment and to detection
accuracy as well as to legal constraints, completely autonomous, self-driving cars will not conceivably roll in the next future on public streets. The benefits, therefore, of CPS in cars will by
and large depend on how human drivers interact with them
The same can be asserted of, e.g., the interaction of physicians with their healthcare infrastructure. Moreover, there are not only the different levels of education and/or training, there
are also the generational leaps, cultural backgrounds, social and wealth discrepancies, and also
the so-called dropouts that cannot afford or do not desire any contact with the new technologies. In general, thus, usability of CPS poses a variety of challenges involving computer-human
interaction and interface design.
5.2 Human Factors
The increasing complexity of systems implies more intricate human-system cooperation. So the
properties of humans, be these of physical or cognitive nature, have an influence on the function
of those systems. Human factors have been in the focus of a series of scientific research activities, and were defined in a number of ways. In this work, we consider this branch of science
as the one that “discovers and applies information about human behaviour, abilities, limitations,
and other characteristics to the design of tools, machines, tasks, jobs, and environments for
productive, safe, comfortable, and effective human use”; see [SM93]. The goal of this investigation can be formulated as “to turn human-machine antagonism into human-machine synergy”;
see [Han97].
Human Factors methods offer a perspective that positively contributes to design. They include several kinds of analysis, including, e.g., human interaction with devices, design of tools
and machines, and general aspects of work and organisational design. The decisive contribution
of these methods is that they bridge the gap between subject experts and systems engineers, and
are used for the correct translation of user requirements into the jargon known to software and
systems engineers. As a result, the design requirements are intelligently interpreted and presented. In [Sta12] case studies are presented showing that Human Factors design interventions
26
resulted in performance improvements between 20-70%.
Understanding the capabilities of humans undoubtedly can help the development of systems
that are ergonomic, i.e., that optimise human well-being. The study of human factors resorts
to many disciplines including anthropometry, physiology, sociology and psychology, and also
of course engineering; see [Gra80]. Such considerations lead to the conclusion that inter- and
transdisciplinary research and development are absolutely necessary.
In addition, and as mentioned above, no special skills or specific training can be demanded
of CPS users. For instance, it cannot be expected a six month availability of a full-time engineer
each time the X-ray unit of an orthopaedist is updated in order to train the surgery’s assistants
in the use of the new apparatus. Therefore, an intuitive and transparent user interaction is indispensable if not vital in order to ensure that a secure shared control takes place, and consequently
any danger is avoided that can be traced back to the inexperienced use of CPS.
There is a series of investigations showing the threat posed by systems that operate in different modes. It cannot be ruled out that the user thinks the system in a mode the system is not,
and he/she is therefore startled to observe an unexpected reaction of the system. In other words,
the actual and the mental model of the system behave contradictorily. This so-called mode confusion is fatiguing and can moreover become critical in safety-related situations. The need to
cope with the sudden violation of his/her expectations, and to do this within seconds, may be an
excessive demand for instance of pilots after hours of flight. Hence, the use of modes should be
carefully considered and if possible avoided; see, e.g., [LPS+ 97, Wey06, Sch07].
Most of the existing research on human factors has only studied how external factors, such
as road signs and warnings from driving assistance systems, affect drivers and traffic. There is,
therefore, the need for research of those issues a priori, i.e., how to consider human factors at
the design stage of systems; see [LYWQ11].
5.3 Seamless interaction in intelligent environments
The concept of Ambient Intelligence, as offered by the report of the Information Society Technologies Advisory Group of the European Commission [IST01] is a vision of the Information
Society where the emphasis is on greater user-friendliness, more efficient services support, userempowerment, and support for human interactions. People are surrounded by intelligent intuitive interfaces that are embedded in all kinds of objects and an environment that is capable of
recognising and responding to the presence of different individuals in a seamless, unobtrusive
and often invisible way; see also [Ste12]. The technological advances envisioned can have particular impact on the very people able to benefit most from these services; at the same time,
without the right support, this new technologies can even add to the exclusion many people
27
suffer (see [Roe07]).
The advances in sensing, including vision techniques, although still somehow rudimentary
(because of the overly demanding computational requisites), allow nevertheless the anticipation
of what in [KMR11] is denominated “intelligent environments”. In order for these to become
real, strategies need be developed that permit the interaction of humans and robots in an (almost)
arbitrary context. In particular, robots should be able to operate electronic devices, interact
with each other (and with humans) as well as with further objects, and meet the demands of
their human users. Research in this area includes autonomy, context and situation awareness,
evaluation, human-machine interface and interaction, user cognition modelling, and energy and
power efficiency.
The associated challenge is the inference of meaningful conclusions, in particular of a safe
course of action, from an increasing number of information sources describing (properties of)
surrounding objects. Besides sensor fusion and data mining techniques, there is the need of pattern mining, visual and sensor data mining, and knowledge grid. These techniques are fed with
methods from many branches of Computer Science as for instance spatio-temporal database systems, machine learning, predictive analytics and, more generally, artificial intelligence, as well
as from statistics; the information itself, of large scale volume, is organised and processed (i.e.,
collected, extracted, analysed, etc.) by warehousing methods. The need for more sophisticated
theories and tools to extract useful information (knowledge) from the growing volumes of digital
data is elaborated as early as 1996 in [FPSS96]. The risk is to “drown in information and starve
for knowledge,” as Rutherford Roger is cited in [HTF09]. Database interoperability and data integration become ineluctable challenges when moving objects, biological, spatio-temporal and
other types of databases must be able to communicate with each other, as needed by many advanced applications; see [Rev10]. There are very many efforts to tackle these problems. For
instance, a general framework is proposed in [DFS+ 12] to encode contextual information from
multiple sources for contextual pattern mining via predicates using a contextual information
graph, and in [DZL+ 12] an approach is proposed that detects irregularly shaped objects.
In any case, and taking into account the envisioned ubiquity of CPS as well as the fact
that very little can be presupposed of the abilities of CPS users, an equilibrium must be found
between usefulness and usage complexity; see, e.g., [OM11, OM12, MB12].
5.4 Shared control
With the increase of systems autonomy, also the expectation of users regarding systems’ reliability rises. This results in new challenges to the human-machine interaction. What if the
28
information and knowledge at disposal lead to a prediction that afterwards proves false?1 , how
are information and knowledge to be correspondingly adapted?
Shared control, i.e., control shared by system and human, needs be realized in order to
achieve a meaningful cooperation between systems and users.2 This is for example the case
when a car system cannot ensure the reliable detection of all obstacles or, in more complex driving situations, invariably an unfailing braking. Also shared-control robotic systems aid surgeons
during surgery. (Here technical, social and legal aspects come together.) The human retains
authority but can also turn his/her attention to other tasks without incurring a performance loss
in the semi-automated task.
The term “shared control” refers to both the autonomy shared by humans and systems, and
to the competences shared by two or more human operators of a system from different perspectives; cf. [FSR+ 12]. As discussed above, in general it cannot be expected a specific knowledge
or special training of systems’ users. Thus, in order to avoid risks that may arise from inexpert
operation of systems, concepts are required that allow an intuitive and transparent user interaction, that provides a secure shared control between humans and systems. This includes, among
other things, transparent directing the user’s attention and unequivocal risk reporting and, on the
other, ensuring that system and users have the same picture of a situation and act accordingly
and consistently.3
Therefore, and in addition to the basic questions of controllability and acceptance of CPS
and the related social issues, another serious challenge is the design of the human-machine
interaction. According to the degree in which people depend on networked technology and
their services, it is equally important to ensure that systems be intuitively operable as well as
individually controlled and understood by users and stakeholders, and this in a shared-controlled
manner.
The International Organization for Standardization, in its Standard ISO 9241-110, describes
usability as
the extent to which a product can be used by specified users to achieve specified
goals with effectiveness, efficiency and satisfaction in a specified context of use;4
1
This applies in case of both false positives (e.g., erroneous detection of a virus) and false negatives (e.g., failure to
detect a virus), both equally nasty misbehaviours.
2
In [BFN06], an architecture for the modes of autonomy in robot intelligence is proposed, increasingly organised
as teleop, safe mode, shared mode, and autonomous mode. The shared control concept defined here refers to at
least the third level of intelligence.
3
Accidents as, e.g., the crash of the flight TK1951 on February 25th, 2009, can be traced back to a faulty collaboration between crew and aircraft, i.e., while operation by shared control. The altimeter was faulty and brought the
plane to landing mode while still at 700m, what was noticed too late by the pilots; see [CNN09].
4
Effectiveness means the accuracy and completeness with which users achieve their specified goals. Efficiency is
the relation of resources expended to the effectiveness. The satisfaction is both the freedom from discomfort and
the positive attitudes of users towards the product. The context of use refers to users, tasks, equipment (hardware,
29
see [ISO09]. In particular, ISO provides general ergonomic principles which apply to the design
of dialogues between humans and information systems:
• suitability for the task,
• suitability for learning,
• suitability for individualisation,
• conformity with user expectations,
• self descriptiveness,
• controllability, and
• error tolerance.
The effectiveness of these criteria can only be ensured if they each are accompanied by a measurement model. The development with humans in the loop is, in this regard, a sine qua non.
Human in the loop (HITL) is a modelling framework that requires human interaction. By HITL,
usually involved but during development hardly consulted stakeholders can nevertheless be encompassed, e.g., by means of mock-ups, in particular in modelling and simulation. Traditional
simulation studies regard human interaction as an external input to the system; CPS, however, include humans as active participants. For instance in the automotive sector, not only systems but
also humans are embedded; see [WBJ08]. So-called human-centred systems are designed, on the
one hand, to preserve or enhance human skills in both manual and office work (see [Bra98]) and,
on the other, to improve humans’ well-being as in, e.g., ambient assisted living; see [AHK+ 12].
In general, one can speak of Human-Centric Cyber-Physical Systems (HC2 PS), a field that has
gained increasing interest; see, e.g., [HU13, LNL+ 12, NSR10, LSL+ 11, SAH13, Lan13].
software, and materials) and physical and social environment.
30
6 Architecture and Platforms for CPS
Architecture and platforms are key components of CPS. The properties envisioned for architecture and platforms in the years beyond 2020 include plug-and-play capability, inter-operability,
self-healing and adaptability Architecture is a most abused terms in engineering. There is hardly
a precise definition but there is a generic consensus that an architecture is a “structural” concept
and that it refers to a set of interconnected components. In the electrical world, the interconnections can be busses, wires, wireless communication channels. In the mechanical world, the
interconnections are the gears, the joints, the articulation points. An architecture is most often
related to physical structures, but it can also be intended in an abstract sense, where the components can be functions and the interconnections the relations between variables of the functions.
In our view, an architecture is then a netlist of possibly abstract components, where the
netlist describes how the variables of the components are related to each other. This definition
encompasses both the abstract and the physical concepts described above.
Note that there is no semantics attached to an architecture, only a syntax that defines what a
well-defined architecture is. For example, the syntax may dictate what the interconnect variables
are and how they should be related to each other. For example, a voltage variable cannot be
connected to a current variable.
In the physical notion of an architecture, the peculiarity of a CPS is the heterogeneity of the
components that form the architecture itself. Note that there may be two different architectures
that describe a CPS: the “physical” one that describes the “plant” and the cyber one that describes
the structure of the cyber components, let this be at the abstract or physical level.
To elucidate these concepts, the example of an aircraft electric power system is provided
next.
6.1 An example of CPS architecture: An Aircraft Electric
Power System
Figure 6.1 illustrates a sample architecture for power generation and distribution in a passenger
aircraft in the form of a single-line diagram (SLD) [MS08], a simplified notation for threephase power systems. Typically, aircraft electric power systems consist of generation, primary
31
L2
GEN
L1
GEN
L
APU
R
APU
R1
GEN
HVAC Bus 1
HVAC Bus 2
HVAC Bus 3
HVAC Bus 4
RU
RU
RU
HVDC Bus 1
RU
HVDC Bus 2
ACT
TRU
R2
GEN
ACT
LVAC Bus 1
LVAC Bus 2
LVAC ESS Bus 3
LVAC ESS Bus 4
RU
RU
LVDC ESS Bus 1
LVDC ESS Bus 2
LVDC Bus 3
LVDC Bus 4
TRU
Batt
Batt
Figure 6.1: Single-line diagram of an aircraft electric power system adapted from a Honeywell,
Inc. patent [Mic08].
distribution and secondary distribution sub-systems. In this example, we focus on the primary
power distribution system, which includes the majority of the supervisory control logic.
Components
The main components of an electric power system are generators, contactors, buses, and loads.
Primary generators are connected to the aircraft engine and can operate at high or low voltages.
Auxiliary generators are mounted atop an auxiliary power unit (APU). The APU is normally
used on ground (when no engines are available) to provide hydraulic and electric power, but can
also be used in flight when one of the primary generators fails. With a small abuse of notation,
we hereafter refer to auxiliary generators themselves as APUs. Batteries are primarily used at
start-up and in case of emergency. AC and DC buses (both high and low-voltage) deliver power
to a number of loads. Buses can be essential or non-essential. Essential buses supply loads that
should always be powered, while non-essential ones supply loads that may be shed in the case
of a fault or limited power capacity.
Contactors are electromechanical switches that connect components, and therefore determine the power flow from sources to loads. They are configured to be open or closed by one or
multiple controllers (not shown in Fig. 6.1), denoted as Bus Power Control Units (BPCU).
Loads include sub-systems such as lighting, heating, avionics and navigation. Bus loads
also include power conversion devices: Rectifier units convert AC power to DC power, while
32
AC transformers (ACTs) step down a high-voltage to a lower one, Transformer Rectifier Units
(TRUs) both decrease the voltage level and convert it from AC to DC.
System Description
The main AC power sources at the top of Fig. 6.1 include two low-voltage generators, two
high-voltage generators, and two APU-mounted auxiliary generators. Each engine connects to
a high-voltage AC (HVAC) generator (L1 and R1) and a low-voltage AC (LVAC) generator (L2
and R2). Panels, denoted as dashed square boxes, represent groups of components that are
physically separated on the aircraft. The three panels below the generators include the HVAC
buses, which can be selectively connected to the HVAC generators, to the auxiliary generators,
and to each other via contactors, denoted by double bars.
Four rectifier units are selectively connected to buses as HVAC loads. The two panels below
the high-voltage DC (HVDC) buses include the LVAC sub-system. A set of AC transformers
(ACTs) convert HVAC power to LVAC power and are connected to four LVAC buses. LVAC
ESS Bus 3 and LVAC ESS Bus 4 are essential and are selectively connected to the two lowvoltage generators. The LVAC essential buses are also connected to rectifier units, and thus to
low-voltage DC (LVDC) power. The LVDC sub-system also contains two batteries. Power can
be selectively routed directly from the HVAC bus to the LVDC buses 3 and 4 using TRUs.
One or more bus power control units use sensors (which are not depicted in Fig. 6.1) to
measure physical quantities, such as voltages and currents, and control the state (open or closed)
of the contactors, to dynamically reconfigure the system based on the status and availability
of the power sources. For the rest of the example, we denote this centralized or distributed
supervisory control unit as BPCU.
System Requirements
Given a set of loads, together with their power and reliability requirements, the goal is to determine the system’s architecture and control such that the demand of the loads is satisfied for all
flight conditions and a set of predetermined faults. For each of these categories, we provide a
few examples that serve as a reference for the rest of the discussion.
Safety specifications constrain the way each bus must be powered to avoid loss of essential
features, and the maximum time interval allowed for power shortages. For instance, to avoid
generator damage, we proscribe AC sources to be paralleled, i.e., no AC bus can be powered by
multiple generators at the same time. Moreover, we refine the definition of essential loads and
buses (such as flight-critical actuators) provided above by requiring that they be never unpowered
for more than a specified time tmax .
33
Reliability specifications describe the bounds on the failure probabilities that can be tolerated
for different portions of the system. Based on its failure modes, every component is characterized
by a failure rate. A failure rate of λ indicates that a failure occurs, on average, every 1/λ
hours. For a given mission profile, failure rates can be translated into failure probabilities so
that system reliability specifications are also expressed in terms of the failure probabilities of the
components. Based on the component failure rates, a typical specification would require that the
failure probability for an essential load (i.e., the probability of being unpowered for longer than
tmax ) be smaller than 10−9 per flight hour. The actual probability value depends on the load
criticality [MS08]. In our example, both the electric power system topology and the controller
should be designed to accommodate any possible combination of faults potentially causing the
failure of an essential component, and having a joint probability larger than 10−9 per flight hour.
Performance requirements specify quality metrics that are desired for the system, in addition
to the safety and reliability requirements reviewed above. For instance, each bus is assigned a
priority list determining in which order available generators should be selected to power it. If
the first generator in the list is unavailable, then the bus will be powered by the second generator,
and so on. A hypothetical prioritization list for the HVAC Bus 1 in Fig. 6.1 would require, for
instance, that L1 GEN has the priority, if available. Otherwise, Bus 1 should receive power from
the R1 GEN, then from the L APU, and finally from the R APU. In a similar way, load management policies are also based on priority tables requiring, for instance, that the available power be
first allocated to the non-sheddable loads and then to the sheddable loads, in a prescribed order.
Priorities are presented as an example of common requirements in electric power system design.
In general bus power priorities can be integrated in BPCU logic and load shedding priorities are
handled by a load management controller.
6.2 Barriers and Challenges for Architecture and Platforms
for CPS
A number of barriers and challenges currently impede progress in the development of CPS
architectures:
• It is technically challenging to identify scientifically-based definitions of measurement
for the broad concepts of security, privacy, safety, and resilience. And if such definitions
are identified, how will they be utilized and reasoned with? For example, if the idea
of privacy is examined, under what conditions or system attributes is privacy considered
violated? These properties could be represented by a variety of models or combinations of
models, which can be chosen based on their compositionality and ability to describe the
constellation of attributes that are being certified. Specific applications include medical
34
device systems (professional, in the loop), smart buildings and vehicles, democratized
power (i.e., allowing users to set and follow policy), and manufacturing or consumption
networks (e.g., food).
• CPS need a structured design method that systematically relates signals and symbols,
both for inter-process communications across domains. Potential application areas include smart manufacturing, cross-domain applications (e.g., modular, fielded robotics),
shared infrastructure data across industries, and the development of a reliable electric grid
increasingly dependent on renewable energy.
• Ensuring the correctness of CPS systems in an uncertain environment is an increasingly
challenging problem. The sheer size, heterogeneity and complexity of CPS make the verification problem even without considering the uncertainty in the environment a nightmare.
Indeed there is no well-established verification environment that can tackle the validation
of CPS in general terms. Environmental uncertainty factors include potential adversaries
and unanticipated human interactions. CPS would not only need to be able to respond
to these environmental factors, but systems would also need to exhibit a degree of reconfigurability and adaptability in order to independently redefine correctness as conditions
change. Specific applications that would benefit the most from addressing this challenge
include autonomous vehicles, aircraft, control systems, the smart grid, and other complex
CPS.
• Currently, there is a lack of infrastructure for use in the evaluation of traditionally closed
systems. This type of evaluation infrastructure can be developed by leveraging the strength
of individual evaluation methods and tools already in use in other systems into an integrated approach, enabling a deeper understanding of the behaviour of both the individual
components and the larger systems. For example, measurement data can be integrated to
drive modelling processes, which in turn can drive simulations and other forms of analysis.
The results of simulations and other forms of analysis can then be used to drive optimized
measurement processes. Specific applications could include CPS components and systems in medicine, the smart grid, smart manufacturing, and transportation. Overcoming
this barrier would also enable the compositionality of different evaluation methods.
These challenges can be met only if an interdisciplinary approach is taken and re-usability
and inter-operability are taken into consideration at the onset of the design. Platforms and
platform-based design [SV07] are concepts that have been introduced over the years to sustain
complex system design including CPS. In VLSI design and in automotive design, the concept of
platform has been used to develop new products in the face of staggering design costs. Systemon-Chip products leverage existing Intellectual Property blocks to assemble integrated circuits
35
with billions of transistors. Volkswagen announced in 2007 its platform strategy1 . The Modular
Transverse Matrix (MQB) platform delivered significant improvements:
• Unit costs 20
• One-off expenditure 20
• Engineered hours per vehicle 30
• Significant weight and emission reduction
Toyota has recently announced a strategy to “copy” VW’s platform approach2 . It is clear that
the platform concept is here to stay. From a “scientific” point of view the first formal definition
of platforms dates back to the early 1990s (see [SV07] for references). In the next section we
provide this definition together with a summary of platform-based design as a method to ease
the design process of CPS architectures.
6.3 Directions for the design of CPS Architecture and
Platforms
Platform-based design (PBD) [SV07] is a paradigm that allows reasoning about design in a structured way. In platform-based design, design progresses in precisely defined abstraction levels;
at each level, functionality (what the system is supposed to do) is strictly separated from architecture (how the functionality can be implemented). Differently than model-based development,
platform-based design consists of a meet-in-the-middle approach where successive top-down
refinements of high-level specifications across design layers are mapped onto bottom-up abstractions and characterizations of potential implementations. Each layer is defined by a design
platform, which is a library (collection) of components, models, representing functionality and
performance of the components and composition rules.
In this context, it is important to: (i) determine valid compositions so that when the design space is explored, only legal (i.e., satisfying the composition rules) compositions that are
compatible are taken into consideration; (ii) guarantee that a component at a higher level of
abstraction is an accurate representation of a lower level component (or aggregation of components); (iii) check that an architecture platform is indeed a correct refinement of a specification
platform, and (iv) formalize top-level system requirements.
1
See http://www.autocar.co.uk/car-news/industry/vw-s-four-platform-future-uncovered
for the latest additions to the platform concept.
2
See http://www.caradvice.com.au/261229/toyota-vice-president-trying-volkswagen-platform-sharin
36
To reason about different requirements in a compositional way, we use the concept of contracts [SVDP12] that formalize the notion of interfaces between models and tools in the design
flow. Contracts can offer a natural framework to reason about distributed control architectures as
well as the heterogeneous interface between the cyber component and its physical counterpart.
Contract-based design was inspired by recent results on assume-guarantee compositional
reasoning and interface theories in the context of hybrid systems and software verification. Informally, contracts mimic the thought process of a designer, who aims at guaranteeing certain
performance figures for the design under specific assumptions on its environment. The essence
of contracts is, therefore, a compositional approach, where design and verification complexity is
reduced by decomposing system-level tasks into more manageable sub-problems at the component level, under a set of assumptions. System properties can then be inferred or proved based
on component properties. In this respect, contract-based design can be a rigorous and effective
paradigm while dealing with the complexity of modern system design, and has been successfully applied to other embedded system domains, such as automotive applications [BCN+ 12]
and mixed-signal integrated circuits [NSVSP12].
Since compatibility is assessed among components at the same abstraction layer, the first
category of contracts is denoted as horizontal contracts. If an environment violates a horizontal
contract, it cannot host any of its implementations.
However, checking horizontal contracts is not sufficient, in general, to guarantee correct implementations. When analysing the behaviour of complex CPS, simplified macro-models can be
used to capture the relevant behaviour of the components at higher levels of abstraction. Therefore, guarantees should also be provided on the accuracy of the macro-models with respect to
models at lower levels of abstraction. These guarantees are captured via bottom-up vertical
contracts. On the other hand, vertical contracts can also be used to encode top-down requirements that system architects introduce to craft the behaviour of a chosen architecture according
to the desired functionality. The above set of constraints can be expressed using top-down vertical contracts. They are used to ensure that an implementation is correct, by checking that the
architecture platform is a refinement of the specification platform.
6.4 Conclusions
Innovative architecture and platforms are needed to support highly complex and inter-connected
CPS. A key consideration is how to enable development and application of comprehensive architectural frameworks that include both the physical and cyber elements of CPS. Other issues to be
considered include what new platforms will be needed to effectively extract actionable information from vast amounts of raw data; and how to provide a robust timing and systems framework
37
to support the real-time control and synchronization requirements of complex, networked, engineered physical systems. Advances will also be needed in sensing, control, and wireless communications to enable optimized performance, diagnostic and prognostic capabilities. Architecture
and platforms are key components of CPS. The properties envisioned for architecture and platforms in the years beyond 2020 include plug-and-play capability, inter-operability, self-healing
and adaptability
38
7 Engineering for integrating cyber and
physical system components
In the previous chapters we have analysed the requirements and the possible limitations related
to the development of a science of CPS, which must be able to address the many issues that
have to do with the special role that CPS’s have in the interaction with the environment and with
human beings. In particular, safety, security and privacy are aspects of primary concern, which
must be designed into the system while ensuring a seamless and natural human-machine interaction. Interoperability and effective communication have also been discussed as fundamental
technologies of CPS.
While a proper science of CPS will result in models and analysis methods that support the
exploration of these issues, their effective implementation requires the development of efficient
engineering processes and design methodologies that can reliably and consistently produce systems that satisfy the desired properties. Of particular importance in the case of CPS is the
integration of the computational infrastructure (the cyber part of the system) with the physical
components and the environment. Key non-functional requirements, such as safety and security,
must also be enforced and guaranteed across the design steps and across the various infrastructures and communication channels employed in the system. In this chapter we discuss some of
the challenges and trends related to these issues.
A recurring property of CPS applications is that they engage all the platform components
simultaneously — from data and computing services on the cloud of large-scale servers, data
gathering from the sensory swarm, and data access on the mobiles. Another property is that
the resulting systems span many scales — in space (from the very large to the very small), in
time (from the very fast to the very slow), in function (consisting of complex hierarchies of
heterogeneous functionalities), and in technology (integrating a broad range of diverse technologies). Each of the components of this distributed platform (compute and data clusters, mobiles/portables, and sensory systems) forms a multi-scale system on its own, and offers some
unique design challenges. Engineers today do successfully design CPS in a variety of industries.
Unfortunately, the development of systems is costly, and development schedules are difficult to
stick to. The complexity of CPS, and particularly the increased performance that is offered from
interconnecting what in the past have been separate systems, increases the design and verifica-
39
tion challenges. As the complexity of these systems increases, our inability to rigorously model
the interactions between the physical and the cyber sides creates serious vulnerabilities. Systems
become unsafe, with disastrous inexplicable failures that could not have been predicted.
There is a widespread consensus in the industry that there is much to gain by optimizing the
implementation phase that today is only considering a very small subset of the design space.
Some attempts at a more efficient design space exploration have been afoot but there is a need
to formalize the problem better and to involve in major ways the different players of the supply
chain. Information about the capabilities of the sub-systems in terms of timing, power consumption, size, weight and other physical aspects transmitted to the system assemblers during
design time would go a long way in providing a better opportunity to design space exploration.
The overarching issue is the need of a substantive evolution of the design methodology in use
today in system companies. The issue to address is the understanding of the principles of system
design, the necessary change to design methodologies, and the dynamics of the supply chain.
In this chapter, we will in particular cover the following issues:
• Section 7.1 deals with the vertical design dimension, discussing the process of abstraction and layered design. We expand in particular on concurrency and timing as the most
relevant aspects.
• Section 7.2 covers in particular the models used in developing CPS, with special attention
to the problem of heterogeneity which is typical of these applications.
• Section 7.3 looks at the horizontal design dimension, which is relatively well studied in
component-based methodologies.
• Section 7.4 discusses the use of models to virtually assemble a CPS and provide early
detection of properties and design flaws.
• Section 7.5 overviews the particular issues related to requirement capture and formalisation in the context of CPS.
• Section 7.6 considers the fundamental role that the development of standards has in improving the process of system integration to decrease uncertainty.
Finally, directions are provided in Section 7.7.
7.1 Abstractions and layered design
Layered design copes with complexity by focusing on those aspects of the system pertinent
to support the design activities at the corresponding level of abstraction (see also Section 6.3
40
above). This approach is particularly powerful if the details of a lower layer of abstraction
are encapsulated when the design is carried out at the higher layer. Layered approaches are
well understood and standard in many application domains. As an example, consider the AUTOSAR standard1 . This standard defines several abstraction layers. Moving from “bottom” to
“top”, the micro-controller abstraction layer encapsulates completely the specifics of underlying
micro-controllers, the second layer abstracts from the concrete configuration of the Electronic
Control Unit (ECU), the employed communication services and the underlying operating system, whereas the (highest) application layer is not aware of any aspect of possible target architectures, and relies on purely virtual communication concepts in specifying communication
between application components. Similar abstraction levels are defined by the ARINC standard
in the avionic domains.
The benefits of using layered design are manifold. For instance, the complete separation of
the logical architecture of an application, represented by a set of interconnected components, and
the target hardware supports complete decoupling of the number of functions from the number
of hardware components. In particular, it is flexible enough to mix components from different
applications on one and the same ECU. This illustrates the double role of abstraction layers,
in allowing designers to focus completely on the logic of the application and abstracting from
the underlying hardware, while at the same time imposing a minimal (or even no) constraint on
the design space of possible hardware architectures. In particular, these abstractions allow the
application design to be re-used across multiple platforms, varying in number of bus-systems
and/or number and class of ECUs. These design layers can, in addition, be used to match
the boundaries of either organizational units within a company, or to define interfaces between
different organizations in the supply chain.
The challenge, then, rests in providing the proper abstractions of lower-level design entities,
which must meet the double criteria of, on one hand, being sufficiently detailed to support virtual
integration testing even with respect to non-functional viewpoints on the next higher level, while
at the same time not overly restricting the space of possible lower-level implementations.
One major challenge in the development of abstractions for CPS is the way timing properties
are represented in the models. The traditional approach in computing is to ignore timing properties whenever possible, and to rely instead on loose synchronization mechanisms or simply
on precedence relations. This approach works well for sequential program execution, since it
greatly simplifies software development. The interaction with the physical world, however, may
not ignore time: in many cases, time becomes an integral property of the function of the system,
and must therefore be accounted for.
Dealing with time raises at least two challenges from an engineering point of view [Lee08]:
1
See http://www.autosar.org/
41
i) the inclusion of the notion of time into the concurrency models, and ii) the development of
computing platforms, communication networks and physical devices that provide consistent,
deterministic and, most importantly, predictable timing behaviour.
The concurrency model is particularly important, since it constitutes the interface by which
the designer deals with interacting components. The most widely used models in software engineering abstract time away and provide unstructured synchronization primitives to support
threaded execution. This form of abstraction is not well suited to CPS development, because of
the poor ability to account for actual timing properties, and due to the extensive non-determinism
that arises during the execution. Stronger properties can be imposed by constraining the way
threads are used in programming. A better approach, however, is to employ alternate models, as
discussed in Section 7.2 below.
Even if well-behaved models are employed in the design, their timing properties can only
be guaranteed by platforms that provide support to predicting their timing behaviour. Unfortunately, decades of innovation have been dedicated to optimising the average execution time, thus
improving throughput, widening the gap with the worst-case execution time (WCET). To make
things worse, the worst-case response is in most cases nearly impossible to determine precisely,
due to the complexity of the architectural solutions.
7.2 Model-Based development
Model-based development (MBD) is today generally accepted as a key enabler to cope with
complex system design due to its capabilities to support early requirement validation and virtual
system integration. MBD-inspired design languages and tools such as SysML2 [OMG10] and/or
AADL [FGH06] for system level modelling, Catia and Modelica [Fri03] for physical system
modelling, Matlab-Simulink [Kar06] for control-law design, and UML3 [BRJ05] Scade [Ber03]
and TargetLink for detailed software design, depend on design layer and application class. The
state-of-the-art in MBD includes automatic code-generation, simulation coupled with requirement monitoring, co-simulation of heterogeneous models such as UML and Matlab-Simulink,
model-based analysis including verification of compliance of requirements and specification
models, model-based test-generation, rapid prototyping, and virtual integration testing as further elaborated below.
In MBD today non-functional aspects such as performance, timing, power or safety analysis are typically addressed in dedicated specialized tools using tool-specific models, with the
entailed risk of incoherency between the corresponding models, which generally interact. To
counteract these risks, meta-models encompassing multiple views of design entities, enabling
2
3
http://www.omg.org/spec/SysML/
http://www.omg.org/spec/UML/
42
co-modelling and co-analysis of typically heterogeneous viewpoint specific models have been
developed. Examples include the MARTE UML [OMG08] profile for real-time system analysis, the SPEEDS HRC meta-model [PHG+ 09, BCF+ 08, BFM+ 08] and the Metropolis and
MetroII semantic meta-model [BWH+ 03, DDM+ 07, SVSS+ 09, DDG+ 13]. In Metropolis and
MetroII multiple views are accommodated via the concept of “quantities” that annotate the functional view of a design and can be composed along with sub-systems. Quantities are equipped
with an “algebra” that allows quantities associated to compositions of sub-systems to be computed from the quantities of each of the sub-systems. Multiple quantities such as timing and
power can be handled simultaneously. Along the same lines, the need to enable integration of
point-tools for multiple viewpoints with industry standard development tools has been the driving force in providing the SPEEDS meta-model building on and extending SysML, which has
been demonstrated to support co-simulation and co-analysis of system models for transportation applications allowing co-assessment of functional, real-time and safety requirements, and
forms an integral part of the meta-model-based inter-operability concepts of the CESAR (see
www.cesarproject.eu) reference technology platform. The SPEEDS meta-model building on and extending SysML has been demonstrated to support co-simulation and co-analysis of
system models for transportation applications allowing co-assessment of functional, real-time
and safety requirements. It forms an integral part of the meta-model-based inter-operability
concepts of the CESAR reference technology platform.
Meta-modelling is also at the centre of the model driven (software) development (MDD)
methodology. MDD is based on the concept of the model-driven architecture (MDA), which
consists of a Platform-Independent Model (PIM) of the application plus one or more PlatformSpecific Models (PSMs) and sets of interface definitions. MDA tools then support the mapping
of the PIM to the PSMs as new technologies become available or implementation decisions
change [OMG13]. This is similar to Platform-Based Design; however, the definition of platform
is not fully described in MDD nor is the semantics to be used for embedded software design. The
Vanderbilt University group [KSLB03] has evolved an embedded software design methodology
and a set of tools based on MDD. In their approach, models explicitly represent the embedded
software and the environment it operates in and capture the requirements and the design of
the application, simultaneously, using domain-specific languages (DSL). The generic modelling
environment (GME) [KSLB03] provides a framework for model transformations enabling easy
exchange of models between tools and offers sophisticated ways to support syntactic (but not
semantic) heterogeneity. The KerMeta meta-modelling workbench [MFJ05] is similar in scope.
43
7.3 Component-based
Whereas layered designs decompose complexity of systems “vertically”, component-based approaches reduce complexity “horizontally” whereby designs are obtained by assembling strongly
encapsulated design entities called “components” equipped with concise and rigorous interface
specifications (see also Section 6.3 above on PBD). Re-use can be maximized by finding the
weakest assumptions on the environment sufficient to establish the guarantees on a given component implementation. While these interface specifications are key and relevant for any system,
the “quality attribute” of perceiving a sub-system as a component is typically related to two orthogonal criteria, that of “small interfaces”, and that of minimally constraining the deployment
context, so as to maximize the potential for re-use. “Small interfaces”, i.e., interfaces which are
both small in terms of number of interface variables or ports, as well as “logically small”, in
that protocols governing the invocation of component services have compact specifications not
requiring deep levels of synchronization, constitute evidence of the success of encapsulation.
The second quality attribute is naturally expressible in terms of interface specifications, where
re-use can be maximized by finding the weakest assumptions on the environment sufficient to
establish the guarantees on a given component implementation.
One challenge, then, for component-based design of embedded systems, is to provide interface specifications that are rich enough to cover all phases of the design cycle. This calls
for including non-functional characteristics as part of the component interface specifications,
which is best achieved by using multiple viewpoints. Current component interface models, in
contrast, are typically restricted to purely functional characterization of components, and thus
cannot capitalize on the benefits of virtual integration testing, as outlined below.
7.4 Virtual integration
Rather than “physically” integrating a system from sub-systems at a particular stage of design,
model-based design allows systems to be virtually integrated based on the models of their subsystem and the architecture specification of the system. Such virtual integration thus allows
detecting potential integration problems up front, in the early phases of development.
Virtual system integration is often a source of heterogeneous system models, such as when
realizing an aircraft function through the combination of mechanical, hydraulic, and electronic
systems — virtual system integration then rests on well-defined principles allowing the integration of such heterogeneous models. Heterogeneous composition of models with different
semantics was originally addressed in Ptolemy [EJL+ 03, BBC+ 05] and Metropolis [BWH+ 03,
DDM+ 07, SVSS+ 09, DDG+ 13] albeit with different approaches. These approaches have then
been further elaborated in the SPEEDS meta-model of heterogeneous rich components [DVM+ 05,
44
PHG+ 09, BCF+ 08, BFM+ 08]. Virtual integration involves models of the functions, the computer architecture with its extra-functional characteristics (timing and other resources), and the
physical system for control. Some existing frameworks offer significant support for virtual integration: Ptolemy II, Metropolis, and RT-Builder. Developments around Catia and Modelica
as well as the new offer SimScape by Simulink provide support for virtual integration of the
physical part at an advanced level.
While virtual integration is already well anchored in many system companies development
processes, the challenge rests in lifting this from the current level of simulation-based analysis of functional system requirements to rich virtual integration testing covering non-functional
requirements. An approach to do so is contract-based virtual integration testing, where both
sub-systems and the complete system are equipped with multi-viewpoint contracts. Since subsystems now characterize their legal environments, we can flag situations, where a sub-system
is used out of specification, i.e., in a design context, for which no guarantees on the sub-systems
reaction can be given. Experience from a rich set of industrial applications shows that such
virtual integration tests drastically reduce the number of late integration errors.
7.5 Requirements
The agendaCPS [GBC+ 12] identifies the area of requirement capture and engineering as one of
primary concern for the correct development of CPS. Requirements play a number of roles in
design, from setting goals and priorities, to establishing the basic properties that the system, the
components and their architecture must satisfy, as well as the way they communicate with each
other and with the outside world. Communication is particularly important for requirement,
given the openness of CPS architectures. In particular, the agendaCPS identifies the following
topics:
• understanding of the open application context, including the user goals and human-computer
interaction, in the form of a formal requirements model;
• understanding the complexity of Systems of Systems grown out of CPS systems, including how to connect them and use them in different contexts, under a central control or
opportunistically;
• understanding the specification of non-functional requirements and their mapping into
architecture design.
In addition, requirement must be able to follow the evolution of CPS by adapting to the context
and the availability of new capabilities, services and infrastructures.
45
In parallel, adequate architecture models and design methods must be developed that reflect
these characteristics. Architecture and interface design needs to be adapted to open contexts of
use, wide-ranging application and integration and uncertain networking and adaptation needs.
In particular, it is necessary to establish concepts for interfaces and protocols and for interactive
and cooperative behaviour, and the research and development of standard communication and
middleware platforms for CPS.
7.6 Standardization
By agreeing on (domain specific) standard representations of design entities, different industrial domains have created their own lingua franca, thus enabling a domain wide shared use of
design entities based on their standardized representation. Examples of these standards in the
automotive sector include the recently approved requirement interchange format standard RIF4 ,
the AUTOSAR5 de-facto standard, the OSEK6 operating system standard, standardized bussystems such as CAN7 and Flexray8 , standards for “car2X” communication, and standardized
representations of test supported by ASAM9 . Examples in the aerospace domain include ARINC
standards10 such as the avionics applications standard interface, IMA, RTCA11 communication
standards. In the automation domain, standards for interconnection of automation devices such
as Profibus12 are complemented by standardized design languages for application development
such as Structured Text.
As standardization moves from hardware to operating system to applications, and thus crosses
multiple design layers, the challenge increases to incorporate all facets of design entities required
to optimize the overall product, while at the same time enabling distributed development in complex supply chains. As an example, to address the different viewpoints required to optimize the
overall product, AUTOSAR extended in transitioning from release 3.1 to 4 its capability to
capture timing characteristics of design entities, a key prerequisite for assessing alternate deployments with respect to their impact on timing. More generally, the need for overall system
optimization calls for the standardization of all non-functional viewpoints of design entities, an
objective yet to be achieved in its full generality.
4
http://www.w3.org/2005/rules/wiki/RIF_Working_Group
http://www.autosar.org/
6
http://www.osek-vdx.org/
7
http://www.iso.org/iso/search.htm?qt=Controller+Area+Network&searchSubmit=
Search&sort=rel&type=simple&published=true
8
http://www.flexray.com/
9
http://www.asam.net/
10
http://www.aeec-amc-fsemc.com/standards/index.html
11
http://www.rtca.org/
12
http://www.profibus.com/
5
46
Harmonizing or even standardizing key processes (such as development processes and safety
processes) provides for a further level of optimization in interactions across the supply chain.
As an example, Airbus Directives and Procedures (ADBs) provide requirements for design processes of equipment manufactures. Often, harmonized processes across the supply chain build
on agreed maturity gates with incremental acceptance testing to monitor progress of supplier development towards final acceptance, often building on incremental prototypes. Also, in domains
developing safety related systems, domain specific standards clearly define the responsibilities
and duties of companies across the supply chain to demonstrate functional safety, such as in the
ISO 2626213 for the automotive domain, IEC 6150814 for automation, its derivatives Cenelec
EN 50128 and 5012615 for rail, and Do 178 B16 for civil avionics.
Yet, the challenge in defining standards rests in balancing the need for stability with the need
of not blocking process innovations.
7.7 Directions
To summarise, the challenges in the realization and operation of these multi-scale systems are
manifold, and cover a broad range of largely unsolved design and run-time problems. These
include: modelling and abstraction, verification, validation and test, reliability and resiliency,
multi-scale technology integration and mapping, power and energy, security, diagnostics, and
run-time management. Failure to address these challenges in a cohesive and comprehensive way
will most certainly delay if not prohibit the widespread adoption of these new technologies.
We believe the most promising means to address the challenges in systems engineering of
CPS is to employ structured and formal design methodologies that seamlessly and coherently
combine the various dimensions of the multi-scale design space (be it behaviour, space or time),
that provide the appropriate abstractions to manage the inherent complexity, and that can provide
correct-by-construction implementations.
The following technology issues must be addressed when developing new approaches to
system design:
• The overall design flows for heterogeneous systems — meant here both in a technical
and also an organizational sense — and the associated use of models across traditional
boundaries are not well developed and understood.
13
http://www.iso.org/iso/catalogue_detail.htm?csnumber=43464
http://www.iec.ch/functionalsafety/
15
http://www.cenelec.eu/Cenelec/CENELEC+in+action/Web+Store/Standards/
default.htm
16
http://www.do178site.com/
14
47
• The verification of “complex systems,” particularly at the system integration phase, where
any interactions are complicated and extremely costly to address, is a common need in
defence, automotive, and other industries.
• Dealing with variability, uncertainty, and life-cycle issues, such as extensibility of a product family, are not well-addressed using available systems engineering methodology and
tools.
• System requirement capture and analysis is in large part a heuristic process, where the
informal text and natural language-based techniques in use today are facing significant
challenges. Formal requirement engineering is in its infancy: mathematical models, formal analysis techniques and links to system implementation must be developed.
• Design-space exploration is rarely performed adequately, yielding suboptimal designs
where the architecture selection phase does not consider extensibility, re-usability, and
fault tolerance to the extent that is needed to reduce cost, failure rates, and time-to-market.
The design technology challenge is to address the entire process and not to consider only
point solutions of methodology, tools, and models that ease part of the design. Addressing this
challenge calls for new modelling approaches that can mix different physical systems, control
logic, and implementation architectures. In doing so, existing approaches, models, and tools
must be subsumed and not eliminated to ensure that designers can evolve smoothly their design
methods and do not reject the proposed design innovations. In particular, a design platform has
to be developed to host the new techniques and to integrate a set of today’s poorly interconnected
tools.
48
8 Conclusions
In this report we analysed the requirements and the possible limitations related to the development of a science of CPS, which must be able to address the many issues that have to do
with the special role that CPS’s have in the interaction with the environment and with human
beings. Particular attention was given to current and future technology and measurement capabilities that can identify crosscutting technical barriers and knowledge gaps limiting innovation
and competitiveness of Europe in CPS.
Five technical topics were considered during the 1st European Experts’ Workshop on CyberPhysical Systems workshop:
1. Reliable, Safe, and Secure Systems
2. Networked, Cooperating Systems
3. Human-interaction systems
4. Architecture and Platforms for Cyber-Physical Systems
5. Engineering for integrating cyber and physical system components
The ideas generated during the 1st European Experts’ Workshop on Cyber-Physical Systems
are summarized in this report and organized around the breakout topics shown above. For each
topic area, discussions are summarized for the future envisioned for CPS systems and technologies, transformative ideas, and the priority challenges that need to be addressed. It should be
noted that the results presented in this report reflect the opinions and ideas of the first expert
workshop participants, not necessarily the entire CPS community.
A first inspection of the situation suggests the need of a shift towards open, interactive systems and living spaces, and associated with it a change of the process of creation, as well as
an integration of infrastructures for interactive and networked services. Among others, interdisciplinary research efforts should focus on enhanced requirements elicitation and on modelling
tools (i.e., modelling languages with a precise semantics) for the possibly user-interactive design
of CPS with adequate human-computer interface enabling suitable interaction and collaboration
as well as distributed and shared control. The considerations in Section 5.2 lead to the conclusion
that a transdisciplinary research and development are absolutely necessary; see also [SHB+ 04].
49
Moreover, technology impact assessments and acceptance research should integrated into this
process; cf. [FFM05, Soc07].
As a follow-on to this summary report, a high-level perspective will be published in the next
report to outline some of the high priority recommendations for future research and development.
In addition, it should include:
• some descriptions of the unique sector-specific challenges and the main tasks needed to
provide the technologies for next-generation cyber-physical systems.
• the availability of recognized educational programs that offer the fundamentals of CPS
though a multi-disciplinary curriculum.
50
Bibliography
[AHK+ 12] Juan Carlos Augusto, Michael Huch, Achilles Kameas, Julie Maitland, Paul
McCullagh, Jean Roberts, Andrew Sixsmith, and Reiner Wichert, editors.
Handbook of Ambient Assisted Living: Technology for Healthcare, Rehabilitation and Well-being, volume 11 of Ambient Intelligence and Smart Environments. IOS Press, 2012. URL: http://ebooks.iospress.nl/volume/
handbook-of-ambient-assisted-living.
[ALRL04]
Algirdas Avižienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr. Basic
concepts and taxonomy of dependable and secure computing. IEEE Transactions
on Dependable and Secure Computing, 1(1):11–33, 2004.
[BBC+ 05] Shuvra S. Bhattacharyya, Christopher Brooks, Elaine Cheong, II John Davis, Mudit Goel, Bart Kienhuis, Edward A. Lee, Jie Liu, Xiaojun Liu, Lukito Muliadi,
Steve Neuendorffer, John Reekie, Neil Smyth, Jeff Tsay, Brian Vogel, Winthrop
Williams, Yuhong Xiong, Yang Zhao, and Haiyang Zheng. Heterogeneous Concurrent Modeling and Design in Java – Volume 1: Introduction to Ptolemy II.
Memorandum UCB/ERL M05/21, Electrical Engineering and Computer Sciences,
University of California at Berkeley, July 2005.
[BCF+ 08]
Albert Benveniste, Benoît Caillaud, Alberto Ferrari, Leonardo Mangeruca, Roberto
Passerone, and Christos Sofronis. Multiple Viewpoint Contract-Based Specification and Design. In Frank de Boer, Marcello Bonsangue, Susanne Graf, and
Willem-Paul de Roever, editors, 6th International Symposium on Formal Methods
for Components and Objects (FMCO’07, Proceedings), Revised Papers, volume
5382 of Lecture Notes in Computer Science, pages 200–225. Springer Verlag Berlin
Heidelberg, 2008.
[BCN+ 12] Albert Benveniste, Benoit Caillaud, Dejan Nickovic, Roberto Passerone, JeanBaptiste Raclet, Philipp Reinkemeier, Alberto Sangiovanni-Vincentelli, Werner
Damm, Thomas Henzinger, and Kim Larsen. Contracts for System Design. Rapport de recherche RR-8147, INRIA, November 2012. URL: http://hal.
inria.fr/hal-00757488/PDF/RR-8147.pdf.
51
[Ber03]
Gerard Berry. The Effectiveness of Synchronous Languages for the Development
of Safety-Critical Systems. White paper, Esterel Technologies, 2003. URL: http:
//www.esterel-technologies.com.
[BFM+ 08] Luca Benvenuti, Alberto Ferrari, Leonardo Mangeruca, Emanuele Mazzi, Roberto
Passerone, and Christos Sofronis. A Contract-Based Formalism for the Specification of Heterogeneous Systems. In Forum on Specification, Verification and Design
Languages (FDL’08, Proceedings), pages 142–147, 2008.
[BFN06]
David Bruemmer, Douglas Few, and Curtis Nielsen. Spatial Reasoning for HumanRobot Teams. In Brian Hilton, editor, Emerging Spatial Information Systems and
Applications, chapter 16, pages 351–373. IGI Global, 2006.
[Bra98]
Harry Braverman. Labor and Monopoly Capital: The Degradation of Work in the
Twentieth Century. Monthly Review Press, 25th anniversary edition, 1998.
[BRJ05]
Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Object Technology Series. Addison-Wesley Professional, 2005.
[BSI12]
Leitfaden Informationssicherheit – IT-Grundschutz kompakt. Technical Report
BSI-Bro12/311, Bundesamt für Sicherheit in der Informationstechnik (German
Federal Office for Information Security), 2012.
[BWH+ 03] Felice Balarin, Yosinori Watanabe, Harry Hsieh, Luciano Lavagno, Claudio
Passerone, and Alberto Sangiovanni-Vincentelli. Metropolis: an Integrated Electronic System Design Environment. IEEE Computer, 36(4):45–52, 2003.
[CAA94]
Report on the Accident to Airbus A320-211 Aircraft in Warsaw on 14 September 1993. Main Commission Aircraft Accident Investigation Warsaw, March
1994. URL: http://www.rvs.uni-bielefeld.de/publications/
Incidents/DOCS/ComAndRep/Warsaw/warsaw-report.html.
[Cav09]
Ann Cavoukian.
Privacy by Design.
Technical report, Information and Privacy Commissioner of Ontario, Canada, 2009.
URL:
http://www.privacybydesign.ca/content/uploads/2010/
03/PrivacybyDesignBook.pdf.
[CNN09]
Faulty reading helped cause Dutch plane crash. CNN, March 2009. URL: http:
//edition.cnn.com/2009/WORLD/europe/03/04/plane.crash/.
52
[CPS08]
Report: Cyber-physical systems summit.
Technical report, CPS Summit, 2008. URL: http://iccps.acm.org/2011/_doc/CPS_Summit_
Report.pdf.
[DDG+ 13] Abhijit Davare, Douglas Densmore, Liangpeng Guo, Roberto Passerone, Alberto
Sangiovanni-Vincentelli, Alena Simalatsar, and Qi Zhu. METRO II: A Design Environment for Cyber-Physical Systems. ACM Transactions on Embedded Computing
Systems, 12(1s):49:1–49:31, March 2013. URL: http://doi.acm.org/10.
1145/2435227.2435245.
[DDM+ 07] Abhijit Davare, Douglas Densmore, Trevor Meyerowitz, Alessandro Pinto, Alberto
Sangiovanni-Vincentelli, Guang Yang, and Qi Zhu. A Next-Generation Design
Framework for Platform-Based Design. In Design Verification Conference (DVCon’07, Proceedings), 2007.
[DFS+ 12]
Weishan Dong, Wei Fan, Lei Shi, Changjin Zhou, and Xifeng Yan. A General
Framework to Encode Heterogeneous Information Sources for Contextual Pattern
Mining. In ACM International Conference on Information and Knowledge Management (CIKM’12 Proceedings), pages 65–74, New York, NY, USA, 2012. ACM.
[DVM+ 05] Werner Damm, Angelika Votintseva, Alexander Metzner, Bernhard Josko, Thomas
Peikenkamp, and Eckard Böde. Boosting Reuse of Embedded Automotive Applications Through Rich Components. In Foundations of Interface Technologies
(FIT’05, Proceedings), 2005.
[DZL+ 12]
Weishan Dong, Xin Zhang, Li Li, Changhua Sun, Lei Shi, and Wei Sun. Detecting
Irregularly Shaped Significant Spatial and Spatio-Temporal Clusters. In Joydeep
Ghosh, Chandrika Kamath, Ian Davidson, Huan Liu, and Carlotta Domeniconi,
editors, International Conference on Data Mining (12th SDM, Proceedings), pages
732–743. SIAM, 2012.
[EJL+ 03]
Johan Eker, Jörn Janneck, Edward Lee, Jie Liu, Xiaojun Liu, Jozsef Ludvig,
Stephen Neuendorffer, Sonia Sachs, and Yuhong Xiong. Taming heterogeneity
– the ptolemy approach. Proceedings of the IEEE, 91(1):127–144, 2003.
[FFM05]
Klaus Fischer, Michael Florian, and Thomas Malsch, editors. Socionics: Scalability of Complex Social Systems, volume 3413 of Lecture Notes in Computer Science.
Springer, 2005.
53
[FGH06]
Peter Feiler, David Gluch, and John Hudak. The Architecture Analysis and Design Language (AADL): An Introduction. Technical Note CMU/SEI-2006-TN011, Software Engineering Institute, Carnegie Mellon University, February 2006.
[FPSS96]
Usama Fayyad, Gregory Piatetsky-Shapiro, and Padhraic Smyth. From Data Mining to Knowledge Discovery in Databases. AI Magazine, 17(3):37–54, 1996.
[Fri03]
Peter Fritzson. Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. John Wiley & Sons, 2003.
[FSR+ 12]
Antonio Franchi, Cristian Secchi, Markus Ryll, Heinrich Bülthoff, and
Paolo Robuffo Giordano. Shared Control: Balancing Autonomy and Human Assistance with a Group of Quadrotor UAVs. IEEE Robotics & Automation Magazin,
19(3):57–68, 2012.
[GBC+ 12] Eva Geisberger, Manfred Broy, María Victoria Cengarle, Patrick Keil, Jürgen
Niehaus, Christian Thiel, and Hans-Jürgen Thönnißen-Fries. agendaCPS: Integrierte Forschungsagenda Cyber-Physical Systems. Springer, Berlin, 2012.
[Gra80]
Étienne Grandjean. Fitting the Task to the Man: Ergonomic Approach. Taylor &
Francis, 1980.
[Han97]
Peter Hancock. Essays on the Future of Human-Machine Systems. BANTA Information Services Group, 1997.
[HTF09]
Trevor Hastie, Robert Tibshirani, and Jerome Friedman. The Elements of Statistical
Learning: Data Mining, Inference, and Prediction. Springer, 2nd edition, February
2009. 10th printing with corrections, January 2013. URL: http://statweb.
stanford.edu/~tibs/ElemStatLearn/.
[HU13]
Teruo Higashino and Akira Uchiyama. A Study for Human Centric Cyber Physical System Based Sensing – Toward Safe and Secure Urban Life –. In Yuzuru
Tanaka, Nicolas Spyratos, Tetsuya Yoshida, and Carlo Meghini, editors, Information Search, Integration and Personalization, volume 146 of Communications
in Computer and Information Science, pages 61–70. Springer Berlin Heidelberg,
2013.
[ISO09]
Ergonomics of human-system interaction – Part 110: Dialogue principles. Technical Report ISO 9241-110:2006, International Organization for Standardization
(ISO), June 2009. URL: http://www.iso.org/iso/iso_catalogue/
catalogue_tc/catalogue_detail.htm?csnumber=38009.
54
[ISO10]
SQuaRE (Software Product Quality Requeriments and Evaluation): Guide to
SQuaRE. Technical Report ISO/IEC 25000:2005, International Organization for
Standardization, 2010.
[IST01]
Scenarios for ambient intelligence in 2010. Final report, IST Advisory Group,
February 2001. Compiled by K. Ducatel, M. Bogdanowicz, F. Scapolo, J. Leijten and J-C. Burgelman. URL: ftp://ftp.cordis.lu/pub/ist/docs/
istagscenarios2010.pdf.
[Kar06]
Steven Karris. Introduction to Simulink with Engineering Applications. Orchard
Publications, 2006.
[KMR11]
Matthias Kranz, Andreas Möller, and Luis Roalter. Robots, Objects, Humans:
Towards Seamless Interaction in Intelligent Environments. In 1st International
Conference on Pervasive and Embedded Computing and Communication Systems
(PECCS’11, Proceedings), pages 163–172. SciTePress, March 2011.
[KSLB03]
Gabor Karsai, Janos Sztipanovits, Ákos Lédeczi, and Ted Bapty. Model-integrated
development of embedded software. Proceedings of the IEEE, 91(1):145–164,
January 2003.
[Lan13]
Brian Lane.
How Cyber-Physical Systems Could Revolutionize “Integrated Industry”.
machining journal, February 2013.
URL:
http://www.thomasnet.com/journals/machining/
how-cyber-physical-systems-could-revolutionize-integrated-industry/.
[Lee08]
Edwared A. Lee. Cyber Physical Systems: Design Challenges. In 11th International Symposium on Object Oriented Real-Time Distributed Computing (ISORC
2008, Proceedings), pages 363–369. IEEE Computer Society, May 2008.
[LNL+ 12]
Wei Liu, Bing Qiang Ng, Terrence Lim, Liu Bin, Boon-Hee Soong, Adnan Nasir,
and Merrill Chia. A novel RFID and capacitive sensing based smart bookshelf. In
18th IEEE International Conference on Networks (ICON’12, Proceedings), pages
92–97. IEEE, 2012.
[LPS+ 97]
Nancy Leveson, L. Denise Pinnel, Sean David Sandys, Shuichi Koga, and Jon Damon Reese. Analyzing Software Specifications for Mode Confusion Potential. In Workshop on Human Error and System Development (Proceedings),
pages 132–146, March 1997. URL: http://sunnyday.mit.edu/papers/
glascow.pdf.
55
[LSL+ 11]
Jianwei Liu, Haiying Shen, Ze Li, Shoshana Loeb, and Stanley Moyer. SCPS:
A Social-Aware Distributed Cyber-Physical Human-Centric Search Engine. In
Global Communications Conference (GLOBECOM’11, Proceedings), pages 1–5.
IEEE, 2011.
[LYWQ11] Xu Li, Xuegang Yu, Aditya Wagh, and Chunming Qiao. Human factors-aware Service Scheduling in Vehicular Cyber-Physical Systems. In 30th IEEE International
Conference on Computer Communications (INFOCOM’2011, Proceedings), pages
2174–2182. IEEE, 2011.
[MB12]
Alessio Malizia and Andrea Bellucci. The Artificiality of Natural User Interfaces.
Communications of the ACM, 55(3):36–38, March 2012.
[MFJ05]
Pierre-Alain Muller, Franck Fleurey, and Jean-Marc Jézéquel. Weaving executability into object-oriented meta-languages. In Lionel C. Briand and Clay Williams,
editors, 8th International Conference on Model Driven Engineering Languages
and Systems (MoDELS’05, Proceedings), volume 3713 of Lecture Notes in Computer Science, pages 264–278. Springer, 2005.
[Mic08]
Rodney Michalko. Electrical starting, generation, conversion and distribution system architecture for a more electric vehicle. USA Patent US 7439634 B2, United
States Patent and Trademark Office (USTPO), October 2008.
[MS08]
Ian Moir and Allan Seabridge. Aircraft Systems: Mechanical, Electrical and Avionics Subsystems Integration. John Wiley and Sons, 3rd edition, 2008.
[Mus04]
John Musa. Software Reliability Engineering: More Reliable Software Faster and
Cheaper. AuthorHouse, 2nd edition edition, 2004.
[NSR10]
Adnan Nasir, Boon-Hee Soong, and Selvakumaran Ramachandran. Framework
of WSN based human centric cyber physical in-pipe water monitoring system.
In 11th International Conference on Control, Automation, Robotics and Vision
(ICARCV’10, Proceedings), pages 1257–1261. IEEE, 2010.
[NSVSP12] Pierluigi Nuzzo, Alberto Sangiovanni-Vincentelli, Xuening Sun, and Alberto
Puggelli. Methodology for the design of analog integrated interfaces using contracts. IEEE Sensors J., 12(12):3329–3345, December 2012.
[OBH+ 13] Afif Osseiran, Volker Braun, Taoka Hidekazu, Patrick Marsch, Hans Schotten, Hugo Tullberg, Mikko Uusitalo, and Malte Schellmann.
The Foundation of the Mobile and Wireless Communications System for 2020 and
56
Beyond:
Challenges, Enablers and Technology Solutions.
In IEEE
77th Vehicular Technology Conference (VTC2013-Spring, Proceedings). IEEE,
2013. URL: https://www.metis2020.com/wp-content/uploads/
publications/VTC_2013_Oss_et_al_MobileSystem2020.pdf.
[OM11]
Kai Olsen and Alessio Malizia. Automated Personal Assistants. IEEE Computer,
44(11):112, 110–111, 2011.
[OM12]
Kai Olsen and Alessio Malizia. Interfaces for the ordinary user: can we hide too
much? Communications of the ACM, 55(1):38–40, January 2012.
[OMG08]
A UML Profile for MARTE, Beta 2. OMG Adopted Specification ptc/08-0609, Object Management Group, August 2008. URL: http://www.omg.org/
omgmarte/.
[OMG10]
System Modeling Language Specification v1.2. Standard specification, Object
Management Group, June 2010. URL: http://www.sysmlforum.com.
[OMG13]
Model Driven Architecture (MDA) FAQ. [online], Object Management Group
(OMG), 2013. URL: http://www.omg.org/mda/faq_mda.htm.
[PHG+ 09] Roberto Passerone, Imene Ben Hafaiedh, Susanne Graf, Albert Benveniste,
Daniela Cancila, Arnaud Cuccuru, Sébastien Gérard, Francois Terrier, Werner
Damm, Alberto Ferrari, Leonardo Mangeruca, Bernhard Josko, Thomas
Peikenkamp, and Alberto Sangiovanni-Vincentelli. Metamodels in Europe: Languages, Tools, and Applications. IEEE Design & Test of Computers, 26(3):38–53,
2009.
[RB11]
Martin Rost and Kirsten Bock. Privacy By Design und die Neuen Schutzziele.
Datenschutz und Datensicherheit (DuD), 35(1):30–35, January 2011.
[Rev10]
Peter Revesz. Introduction to Databases: From Biological to Spatio-Temporal.
Springer, 2010.
[RLSS10]
Ragunathan Rajkumar, Insup Lee, Lui Sha, and John Stankovic. Cyber-physical
systems: the next computing revolution. In Sachin Sapatnekar, editor, 47th Design
Automation Conference (DAC’10, Proceedings), pages 731–736. ACM, 2010.
[Roe07]
Patrick Roe, editor. Towards an inclusive future: Impact and wider potential of
information and communication technologies. COST 219ter. COST, Brussels,
2007. URL: http://www.tiresias.org/cost219ter/inclusive_
future/inclusive_future_book.pdf.
57
[RP09]
Martin Rost and Andreas Pfitzmann. Datenschutz-Schutzziele – revisited. Datenschutz und Datensicherheit (DuD), 33(6):353–358, 2009.
[SAH13]
Amit Sheth, Pramod Anantharam, and Cory Henson. Physical-Cyber-Social Computing: An Early 21st Century Approach. IEEE Intelligent Systems, 28(1):78–82,
2013.
[Sch07]
Andreas Schulz. Driving without awareness – Folgen herabgesetzter Aufmerksamkeit im Straßenverkehr. VDM Verlag Dr. Müller, 2007.
[SHB+ 04]
Neville Anthony Stanton, Alan Hedge, Karel Brookhuis, Eduardo Salas, and
Hal W. Hendrick. Handbook of Human Factors and Ergonomics Methods. CRC
Press, 2004.
[SM93]
Mark Sanders and Ernest McCormick. Human Factors In Engineering and Design.
McGraw-Hill, 7 edition, 1993.
[Soc07]
Special section: Socionics. Journal of Artificial Societies and Social Simulation,
10(1), January 2007. URL: http://jasss.soc.surrey.ac.uk/10/1/
contents.html.
[Sta12]
Neville Stanton. Human Factors Engineering as the Methodological Babel Fish:
Translating User Needs into Software Design. In Marco Winckler, Peter Forbrig, and Regina Bernhaupt, editors, International Conference on Human-Centered
Software Engineering (4th HCSE, Proceedings), volume 7623 of Lecture Notes in
Computer Science, pages 1–17. Springer, 2012.
[Ste12]
Constantine Stephanidis. Human Factors in Ambient Intelligence Environments.
In Gavriel Salvendy, editor, Handbook of Human Factors and Ergonomics, chapter 49, pages 1354–1373. John Wiley and Sons, 4 edition, 2012.
[SV07]
Alberto Sangiovanni-Vincentelli. Quo Vadis, SLD? Reasoning About the Trends
and Challenges of System Level Design. Proc. IEEE, 95(3):467–506, March 2007.
[SVDP12]
Alberto Sangiovanni-Vincentelli, Werner Damm, and Roberto Passerone. Taming
Dr. Frankenstein: Contract-Based Design for Cyber-Physical Systems. European
Journal of Control, 18(3):217–238, 2012.
[SVSS+ 09] Alberto Sangiovanni-Vincentelli, Sandeep Shukla, Janos Sztipanovits, Guang
Yang, and Deepak Mathaikutty. Metamodeling: An Emerging Representation
Paradigm for System-Level Design. IEEE Design & Test of Computers, 26(3):54–
69, 2009. Special Section on Meta-Modeling.
58
[WBJ08]
Daniel Work, Alexandre Bayen, and Quinn Jacobson. Automotive Cyber Physical Systems in the Context of Human Mobility. In National Workshop on
High-Confidence Automotive Cyber-Physical Systems (Proceedings), 2008. URL:
http://varma.ece.cmu.edu/Auto-CPS/Work_Berkeley.pdf.
[Wey06]
Johannes Weyer. Die Zukunft des Autos – das Auto der Zukunft. Wird der Computer den Menschen ersetzen? Soziologische Arbeitspapiere 14, Universität Dortmund, March 2006. URL: http://www.wiso.tu-dortmund.de/wiso/
is/Medienpool/Arbeitspapiere/ap-soz14.pdf.
59

CyPhERS CPS Methods and Techniques

Transcription

Similar documents

Lord Wakeham Letter to Inquiry

Directions for MindPoint Quiz Show

Summer, sun, snaps - Christchurch Photographic Society

The Grove/Issue 3 - St John Paul II CPS

Green Schools - GBBN architects

Harley Lovegrove Industry 4.0

premium patients` kits

REPORT PRINTER MSP 345 STAR