Systems of Systems CPSoSs Bernhard Fr ömel lt froemelvmarstuwienacat gt Institute of Computer Engineering Vienna University of Technology Outline Introduction and Objectives ID: 808477
Download The PPT/PDF document "Interfaces in Evolving Cyber-Physical" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Interfaces in Evolving Cyber-Physical Systems of Systems (CPSoSs)
Bernhard Fr
ömel
<
froemel@vmars.tuwien.ac.at
>
Institute of Computer Engineering, Vienna University of Technology
Slide2OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion
Slide3IntroductionChanging view on how independently owned Cyber-Physical Systems (CPSs) are engineered, operated and evolvedAdvances in telecommunication and automation technologies allowed integration of previously isolated CPSsInternet of Things [Alf15, Dax14], Elastic processing and storage cloudsService-oriented Architectures (SoAs) and their standardization (e.g., Web Services, OPC Unified Architecture)Desire to realize and optimize complex economical processes Integration of CPSs which become Constituent Systems (CSs) of CPSoSs
Time-dependent physical- and cyber interactions
CPSoSs
deliver an emergent service that cannot be realized by single or small number of CSs on their own!
Central to integration of CPSs as CSs of evolving
CPSoSs
are their interfaces!
Slide4CPSoS Example: The Smart GridInteracting consumers, prosumers, and prosumers (e.g., electricity consuming households equipped with electricity producing photovoltaicpower plants) realize optimizedenergy distribution concerningStability of the gridDependability on the grid
Costs associated with the production
of energy
Smart Grids
Handle
h
igh
dynamicity constantly reconfiguring to react to changed energy production & demand conditionsSupport evolution during runtime adaption & extensions towards fulfilling new requirements during runtimeRepresent critical infrastructure high dependability (incl. security and safety) requirements
Slide5Systems-of-Systems in AMADEOSSystem-of-Systems (SoS): An SoS is an integration of a finite number of constituent systems (CS) which are independent and operable, and which are networked together for a period of time to achieve a certain higher goal.Constituent System (CS): An autonomous subsystem of an SoS, consisting of computer
systems and possibly of
controlled
objects and/or human role players
that interact
to provide a given service
.
Environment of a System: The entities and their actions in the UoD that are not part of a system but have the capability to interact with the system.Interface: A point of interaction of a system with another system or with the system environment.Interaction: An interaction is an exchange of information at connected interfaces.Channel: A logical or physical link that transports information among systems [..]
Slide6Interfaces in CPSoSsInterfaces are points of interaction of CSs witheach other direct interactions of CSswith their common environment indirect interactions of CSsTackle CPSoS key challenges related to emergence, dynamicity, evolution, and dependability byIdentification of relevant interfacesProper specification and standardization of interfaces
Managed modification of interface specifications
Interactions over interfaces
time-sensitive in nature
Time plays an important role, also for appearance of desired or avoidance of undesired emergence
Availability of a sparse global
timebase
[Kop11, Kop14a] to temporally coordinate interactions time-aware SoS
Slide7ObjectivesConceptualize time-sensitive interactions in CPSoSsDiscuss architectural elements of CPSoSsIntroduce interface layers in order to manage complexity of cyber-physical interactionsPropose CS interface design to discuss relevant interaction propertiesDiscuss managed evolution of CPSoSs
By applying proposed interface design
Slide8OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion
Slide9Architectural ElementsCPSoS is a System-of-Systems (SoS) consisting of Cyber-Physical Systems (CPSs) as its Constituent Systems (CSs) Architecture of CPSoS definesBoundaries of architectural elements (major building blocks)Relationships among its elements + their environment at useful abstraction levelsArchitecture of CPSoS allows discussion of CPSoS attributes of interest
Many important
CPSoS
attributes
besides purely technical, e.g., related to business, societal, legal
This lecture focuses on behavioral attributes, i.e., interaction relations among architectural elements of
CPSoSs
Architectural ElementsItom (information item comprising of data + explanation): unit of interactionCS: Itom processing entity that exchanges Itoms with its environmentEnvironment: consists of all entities a CS can interact with
Slide10Architectural Element: ItomItom is “timed proposition about some state or behavior in the world” [Kop14b]In some representation object dataAssociated with explanation meta dataAllows for abstraction over the interaction of CSs adhering to different contexts
Representation of explanation/meta data depends on purpose of
Itom
Ontology-based, e.g., conceptual model of Newtonian physics
(Abstract) computer system, see code mobility [Fug98]
Definition of
Itom
is recursiveItoms may contain other ItomsArbitrary complex hierarchical relationships possible, e.g., Itoms could describe (virtual) CSs of a (virtual) SoSExplicit definition of Itoms as unit of interaction for modelling CPSoSsAvoids misinterpretation of exchanged informationEnable automatic Itom transformation systemsEstablishes information context-independence in a CPSoS
Slide11Architectural Element: Constituent SystemCS is a Cyber-Physical System (CPS) consisting ofComputer system is cyber partBehavior + ability to set actions adheres to discrete progression of a digital computer timeInfluenced/observed object is physical partThing obeying physical laws in the dense physical timeCyber part can (1) observe properties of things by sensors, (2) influence properties of things by actuatorsProper integration of dense physical and sparse digital time essentialHumansInteract via Human Machine Interface (HMI) of cyber part and/or directly with physical partPurpose of CS is realization of service allowing CS to benefit from emergent
CPSoS
service
CSs have access to sparse global
timebase
[Kop11]
Timestamp input actions (messages, sensor observations)
Timely generate output actions (messages, actuations)Relevant service of CS only provided/observable at its interfaceInterface specification sufficiently defines CS’s interaction capabilities
Slide12Architectural Element: Constituent SystemComputer system of CS processes ItomsAccording to interface specification that determines all possible behaviors of CSInternals of CS must deliver service defined in interface specificationExact details of service implementation hidden/irrelevantItoms receivedby sensors observing property of physical state in entourage of CS, orR
eceived by messages from cyber space
Itoms
produced
Implemented as influences on properties of things in
entourage
of CS, or
Sent as messages to cyber spaceCS implements time-aware computational element operating on Itoms that are exchanged with CS environment
Slide13Architectural Element: Environment“Environment of a System: The entities and their actions in the UoD that are not part of a system but have the capability to interact with the system.” [Ama16]CS interacts with two kinds of environmentsCyber space: message-based communicationPhysical environment: physical interactions among CSs
Slide14Architectural Element: EnvironmentCyber SpaceDistributed information processing systemExample: IP-based Internet, a planet scale cyber spaceMessage-based communication by direct cyber channels
and
indirect
cyber
channelsDirect: conveys message from one sending to one or more receiving CSs without modificationsIndirect: established over state of shared memory within cyber spaceSending CS modifies shared memory which might be affected by other sending CSs and/or cyber dynamics, i.e., autonomous processes part of the CPSoS architectureReceiving CS obtains (partial) state of shared memoryExample: publish-subscribe communication paradigm [Eug03]
Slide15Architectural Element: EnvironmentPhysical EnvironmentPhysical environment consists of things and physical fields (energy)Properties of physical environment can bemodeled as dynamic network of physicalstate variables described byenvironmental modelCaptures interrelationships (e.g., transfer delays, functional dependencies, location) of
state variables
Networked view allows for
S
imple composition of
environmental models
Consideration of different levels of modeling detail
Taking interfacing effects of CS actuators and sensors into accountExample: Ontology-based environmental model [Höf13]Environmental dynamics (time-sensitive autonomous processes) act on physical state variablesActuators allow CS to act on physical state variablesSensors allow CS to (partially) observe physical state variables
Slide16Concept of Overlapping Entourages of CSsIn physical environment the concept of location/proximity essential, physical interactions often depend on distance force fieldsCS entourage helps to limit size of involved environmental modelsOverlapping entourages of CSs allow for considering stigmergic
information
flows
among CSs
Slide17OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion
Slide18Interface LayersInterface layers enable discussion of interface properties and their definition in interface specificationsAt different abstraction levels/modeling viewpointsExample: Future Combat System Network,see figure on the right,https://en.wikipedia.org/wiki/FCS_NetworkCyber-physical Interface LayerLevel of messages and things/energy
Interactions realized by concrete technology, and
sensors/actuators
Informational Interface Layer
Level of
Itoms
Abstraction over cyber-physical interactions and associated context dependencies
Focus on direct and indirect information flowsService Interface LayerLevel of services, motivated by benefits of Service-oriented Architecture (SoA)Abstraction over individual information channelsUseful for discussing and managing CPSoS dynamicity and evolution
Slide19Cyber-Physical Interface LayerInformation represented by data items Cyber space: a bit patternPhysical environment: properties of things/energyToo detailed for studying many interesting CPSoS properties (e.g., emergence, evolution, dynamicity)Data items are transferred among interacting CSs during Interval of Discourse (IoD) over timeAll cyber interactions at lowest level realized by physical interactions
Time is elemental property of all interactions
Interface properties at cyber-physical layer defined in Cyber-Physical Interface Specification (CP-Spec)
Interface Physical Specification (P-Spec)
Interface Message Specification (M-Spec)
Slide20Physical InterfacesRealized by energy transforming interface devicesSensor: take observations (time-stamped)from physical environment and produces bitpatternActuator: takes a bit pattern and timely sets actions initiated from computer system in physical environmentDelay and jitter affects temporal accuracyFormation of basic
Itoms
Representation: bit pattern
Explanation: Design + placement of sensors/actuators determine semantics of in-/output bit pattern
Physical Specification (P-Spec) describes properties of sensors/actuators
For example: sample rates, value/time uncertainties, observation granularity, …
P-Spec + environmental model allows description/simulation of
stigmergic channelsInput side: formation of basic Itoms from sensor observationsOutput side: how basic Itoms are implemented as influences on properties of things/energy by actuators
Slide21From Basic Itoms to Higher-level Itoms Raw data versus refined dataOften property of a thing (e.g., voltage level) encodes additional meaning (e.g., digital zero and one) to receiversAfter raw data (measured value) has been properly abstracted to refined data the raw data becomes irrelevantRefinement process takes place according to sender/receivers shared conceptual context
Multiple refinement levels possible
Formation of Higher-level
Itoms
Lower-level
Itom
(e.g.,
a basic Itom) transformed to Higher-level Itom byAdding meta data from sender/receivers shared conceptual contextRemoving unnecessary information (raw object data refined object data)Example: speed limit sign at roadside whichshould be interpreted by an autonomous carCamera sensor obtains large array of pixels (basic bitmap Itom) Image classificationContextualization
Speed limit Itom
Slide22Message/Cyber InterfacesCyber interfaces produce/consume messages according to M-Spec consisting of three parts [Kop11]Transport specification: all properties of message needed by involved communication system (cyber space)Syntactic specification: defines named syntactic units called message variables
Semantic specification: links name of message variables to their explanation
Cyber interface can be structured as ports (channel endpoints) where messages are placed for sending, or received messages read from
Port properties: direction, size, type, temporal properties, dependability properties
Syntactic+Semantic
specifications define
Itom
contained in messageDifferent types of compatibility between cyber interfacesContext compatibility: same data (bit pattern) is explained in same way at sender and receiversContext Incompatibility: same data (bit pattern) is explained differently at sender and receiversSyntactic Compatibility: syntactic chunks sent by sender re received by receivers without modificationFull Compatibility (Itom): Itom sent by sender is received by receivers without modification
Slide23Informational Interface LayerInformational layer concerns timely exchange of ItomsValid abstraction over cyber-physical channelsRemoval of details concerning concrete technology (protocols, sensors, actuators, …) that are irrelevant for describing information processing CSsContext-independent [Kop14b] information flowsItoms explicitly specified and maximally refinedValid abstraction demands that underlying cyber-physical channels must adhere to all constraints specified at informational layer (otherwise risk of property mismatch
and
hidden channels
)
Focus on direct and indirect information flows
Indirect information flows allow for
consolidated description of anonymous CSsdecentralized coordination [Val04]description of cascading effects [Fis06]Itom channels specified in Interface Itom Specification (I-Spec) and characterized by What kind of Itoms transportedSender and receiversTemporal and dependability properties
Slide24Example: Emergency Braking At informational layer: CS car notifies other cars about its sudden change of velocity to immediate stop by Itoms related to ‘emergency brake’Possible implementations at cyber-physical layerStigmergic channel among braking car and cars behindStigmergic channel realized by brake light at sender and human operators of cars behindWireless car2car cyber channel
Slide25Direct vs. Indirect CommunicationDirect communicationItoms transferred unidirectionally from one sender to one or more receiver CSsSimple channel model (input, delay/jitter, output)Behavior of interaction within interacting CSsIndirect communicationItoms of sending CS affect state of common environment of interacting CSsEnvironmental dynamics influence state as wellReceiving CSs can (partially) read state of common environment
Received
Itoms
reflect totality of all influences carried out on state in common environment
Senders and receivers need to share conceptual context such that receivers can form higher-level
Itoms
, i.e., access purpose/intention of senders
Indirect channel can be modeled by an Environmental Constituent System (ECS) that realizes common environment of interacting CSs Not all systems involved in an interaction need to be modeled explicitly as long as their effects are considered as environmental dynamics Indirect communication often closes causal feedback loops
Slide26Service Interface LayerSystem behavior structured as capabilitiesGroups (sub)service/capability related Itom channelsDescribes common characteristics and interrelationships of grouped Itom channels, i.e., interaction patternsExample: database service consisting of a request and a response Itom channelCS in need of a service is matched to a service providing CSService-oriented Architecture (SoA) principles
CS in need of capabilities (service consumers) + CS offering that capabilities (service providers) brought together by means of
Service registry: repository of interface service specifications (S-Specs)
S
ervice discovery: process where service consumers match their requirements with service registry
S
ervice composition: integration of multiple services into a new service
Immediate reduction of cognitive complexityNecessary Itom channels can be (offline) instantiated by a scheduler/composition mechanismService composition/hierarchy of lower-level service to a higher-level serviceExample: service that provides humanoid robot capability to open doors consisting of several lower-level servicesLoose coupling of CSsActual constituents of a service unimportant background detailsAllows for self-organized SoS reconfiguration towards optimal usage of available resources
Slide27Service Interface LayerInterface Service Specification (S-Spec)Set of quality metrics available to an independent observer to determine quality of provided serviceService provider offers its capabilities under a Service Level Agreement (SLA)SLA is based onConstraints of quality metrics codified in Service Level Objectives (SLOs)Compensation actions in case SLOs are violated despite a committed service Service providers publish their SLA with reference to S-Spec of an offered service at service registry
Slide28OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion
Slide29Interfaces of a Constituent SystemTime-Sync Interface: External sync. to realize sparse global timebaseRUI: CPSoS as a whole relies on this interface of its CSs to provide emergent CPSoS serviceUtility InterfacesLocal I/O Interface for interaction with local environment of CS irrelevant to SoS
service, e.g., Human Machine Interface (HMI)
Configuration Interface to update RUI specification (hardware, software upgrade) management of
CPSoS
evolution
Diagnosis Interface for monitoring management of
CPSoS
dynamicity
Slide30RUI Connecting Strategy“RUI Connecting Strategy: Part of the interface specification of RUIs is the RUI connecting strategy which searches for desired, w.r.t. connections available, and compatible RUIs of other CSs and connects them until they either become undesirable, unavailable, or incompatible.” [Ama16]Example: In the Global Automated Teller Machine (ATM) network a cardholdertogether with smartcard-based payment card form a CS that
is most
of the
time
disconnected
from other CSs.
The RUI
connecting strategy of the payment card CS is influenced by cardholder’s need for cash (desire), nearby located and operational ATM terminals (availability), and whether the ATM terminal accepts the payment card (compatibility).
Slide31Roles of the Relied Upon Interface (RUI)System boundary: Structural decomposition of CPSoS into Constituent Systems (CSs) at RUIsComplexity firewall: RUI specification hides possibly complex behavior of CS from CPSoS and vice versaInformation transfer: All for the overall CPSoS operation relevant interactions occur at RUIsEmergence: Identified purpose of CPSoSs is to realize emergent services which are located in CSs interactions at RUIsDynamicity: Short-term changes (e.g., number of CSs varies, faults) need to be considered in RUI specification
Evolution: Long-term changes (e.g., new emergent
CPSoS
services) affect how RUI specifications are updated
Concept RUI and its semantic relationships of other concepts are at core of AMADEOS conceptual model
Slide32Interface Layers of RUIsExamination of RUIs at the introduced interface layersPresent RUI model at the different layersShow how RUI interface layers are connectedFocus on informational interface layerMost suitable interface layer to study CPSoS properties concerning emergence, dynamicity and evolutionPropose a time-aware execution semantics of RUI model to study CPSoS properties
Slide33RUI at the Cyber-Physical Layer
Slide34RUI at the Cyber-Physical LayerTwo CSs shown that have access toglobal timebaseExternally time-synchronized by e.g., GPSIntroduce two RUI subinterfacesRelied Upon Message Interface (RUMI)Unidirectional transport of state & event messages [Kop11] by means of conventional direct cyber channelsState message only contains state observations (e.g., temperature of a room)Indirect coordination with other CSs by means of indirect cyber channelsRelied Upon Physical Interface (RUPI)
Consists of interface devices: sensors and actuators
Interface devices act and observe entourage of CS
Overlapping entourage of CSs allow
stigmergic
channels/information flows
All interactions are indirect and over the common environment
Slide35RUI at the Informational LayerUnifies all physical and cyber interactions of cyber-physical layer by abstracting overConcrete implementation technology (e.g., used sensors, actuators, message transport)Informational context-sensitivity by using explicitly defined Itoms (object + meta data)Focus on direct and indirect information flows among CSsIndirect channels modeled by instantiation of an additional Environmental CS (ECS)Informational layer useful for study of CPSoS properties during design and evolutionEmergence: informational layer captures all causal relations among CS interactions, allowing the analysis of emergence
Requires RUI specifications and associated interface models, and environmental model
In case of observed differences to cyber-physical layer (monitored actual interactions and actual occurrence of unpredicted emergence): possible presence of hidden channels
Hidden channel is latent information flow among CSs not considered in the models
Managed dynamicity: Investigate prompt
CPSoS
reactions to changes in environment
Managed evolution: Investigate how to steer CPSoS towards a desired evolutionary state while avoiding negative emergence
Slide36RUI at Service LayerIntroduction of Relied Upon Service (RUS)Provided at RUI of a CSDescribed in service interface specification (S-Spec) as set of RUS-related operationsRUS operation is behavioral abstraction over one or more unidirectional Itom channels
Groups
Itom
channels together
Specifies interaction pattern, i.e., sequence of operation-related
Itoms
over all channel endpoints from perspective of RUS provider
Examples for interaction patterns: request-response, notify, solicit, …S-Spec + associated SLA published by RUS provider at service registryIndependent observer (in particular RUS consumer) can check whether Service Level Objectives (SLOs) are fulfilledService registry depending on business requirements of SoS can either be Another CS (operated by an SoS authority) to allow RUS composition during CPSoS runtime, orRealized in an off-line manner where RUS providers and consumers are matched during e.g., manufacturingEmergent CPSoS service modeled as set of dependencies of required RUSsRequired RUSs must be provided by a CS that wants to benefit from emergent CPSoS serviceCS does not need to provide RUS directly, but can use composition of other RUSs provided by other CSs (see [Frö16, Section 4] for an example)
Slide37Connected RUS Interface Layers, ExampleSmall artificial example of a CPSoS at all interface layersDemonstrated characteristicsInteracting n CSsDirect cyber-channelsIndirect cyber-channelsStigmergic channelsVisualized related cyber-physical channels, Itom channels, and service endpointsSame color is used for related channels and service endpoints
Service endpoint is
Itom
port description from perspective of RUS provider
Slide38Connected RUS Interface Layers, ExampleCyber-Physical Layer
Slide39Cyber-Physical interactions
realized by some concrete technology
Example: TCP/IP stack, physical
location of CS on street influenced
by actuators
Cyber Channels (CC) and Physical Channels (PC)
CC 1 and CC 2 are direct cyber channels
of
the
same RUS
Example
: a
database
lookup
service
realized
by
request
-response
channels
)
CC 3 and CCs originating from CS3 to n-1 are writers of an indirect channel, CS n is reader which observes shared memory via CC 4
Example: writers publish whether an alarm occurred, CS n is alarm monitor
Stigmergic
channel (green) where all CSs are able to influence physical state variables and also observe them
Example: position of CSs on a street
Connected RUS Interface Layers, Example
Cyber-Physical Layer
Slide40Connected RUS Interface Layers, ExampleInformational Layer
Slide41All direct CCs have
corresponding
Itom
Channel (IC)
For example, IC 1 corresponds
to CC 1
Indirect CC is realized by
additional Environmental CS (ECS)
ECS implements behavior of indirect CC described by environmental model (shared memory + cyber dynamics)
For each
stigmergic
channel also an additional ECS is instantiated
ECSs described by environmental model (physical state variables + environmental dynamics)
Connected RUS Interface Layers,
Example
Informational Layer
Slide42Connected RUS Interface Layers, ExampleService Layer
Slide434 services in the shown dependency relation
Service A depends on
Env
. Services C and D
Env
. Service B depends on
Env
. Service D
Incoming and outgoing arrows on left of service vertex symbolizes
Itom
channel endpoints from perspective of service provider
Service A is, for example, a database lookup service provided by CS 2 and has one request input port and one response output port
Both are instantiated to
Itom
channels per service consumer
3 environmental services (B, C, D) provided by
ECS at informational layer, e.g.,
Env
. Service D is provided by ECS 3
environment (cyber space or physical environment) at cyber-physical layer
CSs that consume environmental services act either as influence/writer or observer/reader
Ports on left side of environmental services represent influence/writer service consumer
Example: CS 1 is an influence/writer of ECS 2
Ports on the right side represent observer/reader service consumer
Example: CS 2 is an observer/reader of ECS 2
Connected RUS Interface Layers,
Example
Service Layer
Slide44Execution SemanticsInformational RUI ModelInterface model describes part of system behavior that is observable at interfaceInterface specifications describes only interfacing properties regarding environment, but not behavior or CS environment itselfNeed for an appropriate execution semanticsFrame-based Synchronous Dataflow Model (FSDM)Well defined semantics in value domain and temporal domainEmployed to model (for design and analysis) dependable, even safety-critical, distributed real-time systems,
e.g
.,
GIOTTO [Hen01],
Lustre
[Hal91
]
FSDM is an appropriate execution semantics for studying behavioral properties of CPSoSs at informational layer
Slide45Frame-based Synchronous Dataflow Model(FSDM)Integration of physical- and cyber domain to information processing systemDense physical time segmented in frames, i.e., periodic sequences of constant durationFrame consists of synchronization phase and processing phaseSynchronization phase: write output to environment and read input (sample & hold) from environmentProcessing phase: calculate next state and output from input and current stateAccording to synchronization hypothesis [Pot05] frame duration is short enough such that system appropriately reacts to changes in its
environment
Frame duration determined by environmental dynamics, e.g., keyboard-based HMI: 50
ms
, crash sensor in a car: 1
ms
No interactions occur within frame, only at synchronization phase!
Slide46Frame-based Synchronous Dataflow Model(FSDM)Implementation of CPSoS architectural elements in FSDMItom: Data flows in FSDM transport Itoms which are input/output elements of CSs and Environmental CSs (ECSs)Direct Itom Channel Model: a subsystem connected to a sender CS and one or more receiver CSs, store and forward of Itoms
CS and ECS RUI Models: RUI models connect to channel models according to
RUI connecting strategy
Implementation technologies for cyber-physical layer
Sparse global
timebase
‘drives’ periodic control system
Processing phase: task activationCommunication phase: send/receive actionsState estimation [Kha13] available to relax synchronization hypothesisExamplesTTEthernetTTSoC/ACROSSTTP/C
Slide47RUIs under Dynamicity“Dynamicity of a system: The capability of a system to react promptly to changes in the environment” [Ama16]Dynamicity needs to be already be considered during CPSoS design timeNeeds to be part of the RUI specificationPrototypical dynamicity casesDynamicity concerning connecting two or more CSs at their RUIs,Dynamicity in making (partial) CS or emergent CPSoS services available to other CSs (RUS composition), andDynamicity to adapt to changes in the environment.
CPSoS
boundary determined by
RUI connecting strategy
RUIs might only be temporally connected, disconnected RUIs might be fault-free interface state
No static
CPSoS
boundaryCSs may disconnect and reconnect, may even be part of multiple SoSsExample: a modern smart phone can be part of the global telephone network, the global ATM network, or part of the InternetRUI connecting strategy defined in RUI specification and regulates how CSs establish connectionsAll RUI connecting strategies are local to the respective CS, still influence dynamic global network topology of SoSRUI connecting strategy co-responsible for emergence in CPSoS
Slide48OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion
Slide49Interfaces in Evolving Cyber-Physical Systems-of-Systems (CPSoSs)Evolution of CPSoSs concerns design modifications introduced into interacting CSs triggered by changes in environmentAdvances in technologyChanges in societal or business needsNeeds for change originating from
W
ish towards increased efficiency
Introduction of new services
Evolutionary changes to design and operation of
CPSoS
should
Counteract obsolescence to keep CPSoS relevantIncrease CPSoS business valueNot deteriorate already provided and still needed servicesIn large systems like CPSoSs distinction between unmanaged evolution and managed evolution [Mur01]
Slide50Unmanaged Evolution vs Managed EvolutionUnmanaged evolution appropriate for virtual SoSsNo guidance about how CPSoS evolvesCS owners freely change services and cooperation with other CSs motivated by each CS’s perceived gain in business valueNo clear central purposeManaged evolution [Mur01] most appropriate for
collaborative
SoSs
[Ama16]
(but also
directed
and acknowledged SoSs)Originally suggested in the context of large, long-term operational software systemsPlanned and supervised by an SoS authority, i.e., an organizational entity such that “the efficiency of developing and operating the system is preserved and increased” [Mur01].SoS authorityHas specific purpose for CPSoS in mindMaintains RUI interface specificationsHas a set of capabilities to (1) introduce changes into RUI specifications, (2) monitor evolutionary performance, and (3) give incentives to CSs to adopt changed RUI specifications
Slide51Scope and ChallengesScope: Focus on technical aspects of managing evolution of time-aware CPSoSsMain challenge: Maintain CPSoS agility, i.e., the ability to efficiently implement evolutionary changes, while carrying out necessary changes to increase system’s business value.Continuous Evolution: in CPSoSs no redesign and deployment from scratch possible need for continuous evolution during runtimeMulti-version Evolution: no simultaneous replacement/upgrade of all CSs possible
parts of
CPSoS
are in different evolutionary states, possibly CSs become
legacy systems
that need appropriate wrappers
Unexpected Detrimental Emergence: evolutionary changes may lead to unexpected and undesired emergence unexpected emergence cannot be easily predicated, might only be discovered by accidentEvolving CPSoS Dynamicity: AMADEOS CPSoSs feature architectural support for adaptive monitoring, analyzing and planning via cognitive and predictive models, and executing reaction strategies architectural means to handle CPSoS dynamicity need to evolve together with changes in the CPSoS serviceMore challenges if specific CPSoS
application domains are considered
Slide52Local and Global EvolutionLocal Evolution concerns changes within CS not affecting RUINo modification of RUI specificationImportant to optimize CS internalsAllows preparation of a global evolutionary stepHarbors risk of introducing hidden channels, i.e., unconsidered interactions, among CSs which could lead to emergent effectsStrict adherence to RUI specification required which forbids any undefined interactionsGlobal Evolution affects interactions of CSsChange of RUI specification and how changes come into effectTo support continuous evolution, changes to CPSoS carried out in evolutionary steps of limited scope with preferably predictable effects
Global evolution can be seen as a tree-like search towards adaptation to environmental changes, similar to Darwin and natural selection in biological evolution
Slide53Tree-like Search towards AdaptionVertices represent specific evolutionary states/versions of CSsEdges represent evolutionary steps
Slide54Tree-like Search towards AdaptionVertical dashed line represents instant now which separates past (versions of CSs that exit and may or may not be in operation) from future (versions of CSs that are planned and not operational yet)
Slide55Tree-like Search towards AdaptionSome versions of CSs are compatible at the presentIndicated compatible versions with upper and lower lassos
Slide56Tree-like Search towards AdaptionIn some cases a version is abandoned and not evolved any further, indicated by shaded vertex which has no outgoing edge. CSs of such abandoned version will turn into legacy CSs until obsolete.
Slide57Tree-like Search towards AdaptionTypes of Evolutionary StepsBasic StepLinear, incremental update from one version of a CPSoS to the next oneForkTwo ore more different versions evolve from same ancestor versionExample: A smart grid CPSoS might have evolved in one country up to certain version which is adopted by a different CPSoS consortium in another country. Over time these two versions might diverge further up to a point where not compatible anymore.
Forks mostly associated with creation of business value
Merge
Two versions of CSs that are part of same
CPSoS
might merge in a later version to reduce unnecessary functional redundancies, benefit from standardization efforts, or consolidated interfaces
Merges often increase agility
Objective of CPSoS authority to appropriately control evolutionary steps such that business value for all stakeholders stays viable while agility is not reduced.
Slide58SoS AuthoritySoS authority mandatory organizational entity of collaborative SoSsHas societal, legal, or business responsibilities to keep CPSoS relevant to stakeholdersHas monitoring and amelioration powers to steer evolution towards desired target versionComposed of key CPSoS stakeholdersFor example, CS manufacturers or governments
Manages RUI specifications and controls how changes take place
Selects appropriate set of standards
Slide59Management of RUI SpecificationsAuthorized Relied Upon Services (RUS) specifications (S-Specs) are administrated at service registryOnly SoS authority can authorize and publish S-SpecsCS owner can participate in CPSoS by offering a RUS compliant to authorized S-Spec Service registry supports version management, i.e., multiple versions of a RUS can coexistCS owners specify in the Service Level Agreement (SLA) to which version of S-Spec they refer toEvery supported S-Spec version has its own SLA
Slide60Assessing and SteeringEvolutionary ProcessPerformance of evolutionary process derived from measurable quality metrics describing business value and agilityIntegration of performance measurement possible in AMADEOS solutions concerning CPSoS dynamicityImportant quality metric is the adoption rate of existing and newly introduced CSs to new or changed versions of S-SpecsAdoption rate is controllable by SoS authority by giving incentivesExample: In the Global Automated Teller Machine (ATM) network
SoS
the payment card industry shifted liability at a specified deadline from money institutes to the Point of Sale (
PoS
) operators (usually merchants), if they used old and insecure equipment for payment processing.
Minor versus Major evolutionary step
Minor evolutionary step only affects how cyber-physical interactions are carried out while at informational and service layer there is no change
Major evolutionary step affects informational or service interface layer requiring more careful planning/execution concerning detrimental emergence and management of dynamicity
Slide61Handling Continuous EvolutionTransition from one CPSoS version to an evolved versionPrinciple of backwards-compatibility of CSs: upgraded or newly introduced CSs need to be able to interact with non-upgraded CSsTime-aware CPSoS the global timebase can be used to temporally coordinate the execution of evolutionary stepsDefinition of validity instants of RUI specifications allow switching to new version of a RUI specification at specific instantFor example: a desired emergent effect only occurs if a critical number of CSs adhere simultaneously to an upgraded RUS versionIn other cases it might be beneficial to reach a safe/ground/dormant state first, then perform (physical) upgrades, and wake CSs up again in an evolved
CPSoS
(cf. car-recalls and repair procedures in automotive domain)
Slide62Avoiding Detrimental EmergenceOccurrence of unexpected, detrimental emergence problematic case in engineering, operating, and evolving CPSoSsAgainst expectations and current predictive capabilities something harmful happenedCPSoSs are open systems that interact with their possibly changing environmentChanging environment invalidates environmental models used to predict, e.g., security/safety properties of a CPSoSIncomplete environmental model leads to unconsidered interactions among CSs, i.e., hidden channelsBoundary of a CPSoS is not static
influences how
CPSoS
environment affects
CPSoS
itself
Example:
Consider a fault-tolerant CPSoS. If the number of its redundant CSs is small, an environment that causes intermittent faults in CSs at a constant rate (e.g., radiation) is much more hostile than compared to the same CPSoS where the number of redundant CSs is large.Two co-dependent causes that enable occurrence of unexpected (detrimental) emergence:Evolutionary step that changes how CSs interact, andA change in the CPSoS environment and/or hidden channels
Slide63Mitigation StrategyAugmentation of CPSoS design with expectations about nominal operationRUS specifications should contain assertions indicating if provided RUS is consumed nominallyRuntime monitoring can check defined assertions and log anomalies with timestampDiscovery of the onset of unexpected emergent phenomenaBy quality metrics associated with onset of emergence (e.g., critical slow-down, density), unexplained anomalies, and patterns of previously diagnosed emergenceDiagnosis and analysis of unexpected emergenceDiscovered unexpected emergence needs to be carefully analyzed and trans-ordinal laws
and possibly
hidden channels
must be found
Possibly inaccurate
environmental models
must be updated
Prevention of detrimental emergence by designEvolutionary step can (1) introduce proper constraints of CS interactions by means of changes to the RUI specifications, and (2) implement prevention strategies (dynamicity)Example: Introducing randomness to break unintended synchronization [Mog06]Prediction of detrimental emergenceUse analytical methods (e.g., finding causal loops, cascading effects) as well as simulation of models
Slide64Detecting Unknown EmergenceLooking for something unknown that does not have any generic or unique characteristics difficultEmergence often associated with a pattern/structure/regularities or shift in densities[Mog06] suggests building library of signatures of emergenceExamples: trashing caused by ‘unlucky’ scheduling (not just overprovisioning), unintended synchronization, unintended oscillation, …Requires initial decision procedure to classify anomalies as emergence but good for detecting (similar) known emergenceDecision procedure to classify unknown anomalies could be based on unsupervised machine learning
Slide65Self-Organizing Maps (SOMs) reveal Emergent RegularitiesSOM [Koh01] is an unsupervised machine learning approach based on artificial neural network of a usually low-dimensional topology where high dimensional data is mapped to in order to identify structure/patterns.
Slide66ConclusionDiscussed time-aware CPSoSs for purpose to investigate behavioral properties of CPSoSsCharacterized relevant architectural elements of CPSoSsIntroduced three interface layers: cyber-physical layer, informational layer, service layerIdentified and discussed the Relied Upon Interface (RUI) of CSs as fundamental interface responsible for operational behavior of CPSoSs and managing CPSoS evolution
Presented RUI model at introduced interface layers
Example how interface layers are connected
Execution semantics of RUI model at informational layer
Based on a Frame-based Synchronous Dataflow Model (FSDM)
Useful to explore behavioral
CPSoS
properties concerning emergence, dynamicity, and evolutionPresented CPSoS dynamicity management mechanisms based on RUI specifications
Slide67ConclusionDiscussed CPSoS evolution and how to manage it by controlled modifications of RUI specificationsIntroduced CPSoS authorityIn control of RUI specificationsPlans and carries out evolutionary steps by changing RUI specificationsBoth changes in CPSoS environment and evolutionary changes harbors risk of unpredictable emergenceSuggested mitigation strategy
Slide68Some References[Alf15] Al-Fuqaha, Ala, et al. "Internet of things: A survey on enabling technologies, protocols, and applications." IEEE Communications Surveys & Tutorials 17.4 (2015): 2347-2376.[Ama16] AMADEOS Consortium. “D2.3 – AMADEOS Conceptual Model – Revised.”
2016.
[Dax14]
Da Xu, Li, Wu He, and
Shancang
Li.
"Internet of things in industries: A survey."
IEEE Transactions on Industrial Informatics 10.4 (2014): 2233-2243.[Eug03] Eugster, Patrick Th, et al. "The many faces of publish/subscribe." ACM Computing Surveys (CSUR) 35.2 (2003): 114-131.[Fis06] Fisher, David. "An emergent perspective on interoperation in systems of systems." 2006.[Frö16] Frömel, Bernhard. “Interface Design in Cyber-Physical Systems-of-Systems.”
System of Systems Engineering Conference (SoSE), 2016 11th. IEEE, 2016
.[Fug98] Fuggetta, Alfonso,
Gian
Pietro
Picco
, and Giovanni
Vigna
.
"Understanding code mobility."
IEEE Transactions on software engineering 24.5 (1998): 342-361
.
[Hal91
]
Halbwachs
, Nicholas, et al.
"The synchronous data flow programming language LUSTRE."
Proceedings of the IEEE 79.9 (1991): 1305-1320
.
[Hen01
]
Henzinger
, Thomas A., Benjamin Horowitz, and Christoph Meyer Kirsch.
"Giotto: A time-triggered language for embedded programming."
International Workshop on Embedded Software. Springer Berlin Heidelberg, 2001
.
Slide69Some References[Höf13] Höftberger, Oliver, and Roman Obermaisser. "Ontology-based runtime reconfiguration of distributed embedded real-time systems." 16th IEEE International Symposium on Object/component/service-oriented Real-time distributed Computing (ISORC). IEEE, 2013.
[
Kah13
]
Khaleghi
,
Bahador, et al. "Multisensor data fusion: A review of the state-of-the-art." Information Fusion 14.1 (2013): 28-44.[Koh01] Kohonen, Teuvo. "The basic SOM."
Self-organizing maps
. Springer Berlin Heidelberg, 2001. 105-176.[Kop11
]
Kopetz
, Hermann.
“Real-time systems: design principles for distributed embedded applications.”
Springer Science & Business Media, 2011.
[Kop14a
]
Kopetz
, Hermann.
"Why a Global Time is Needed in a Dependable
SoS
."
arXiv
preprint arXiv:1404.6772 (2014).
[Kop15b
]
Kopetz
, Hermann.
"A conceptual model for the information transfer in systems-of-systems."
2014 IEEE 17th International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing. IEEE, 2014
.
[Mog06]
Mogul, Jeffrey C.
"Emergent (
mis
) behavior vs. complex software systems."
ACM SIGOPS Operating Systems Review. Vol. 40. No. 4. ACM, 2006.
[Mur01]
Murer
, Stephan, Bruno
Bonati
, and Frank J.
Furrer
.
"Managed evolution."
(2011).
[Val04
]
Valckenaers
, Paul, Martin
Kollingbaum
, and Hendrik Van Brussel.
"Multi-agent coordination and control using
stigmergy
."
Computers in industry 53.1 (2004): 75-96.
Slide70Image/Photo Creditshttps://de.wikipedia.org/wiki/Energiewende#/media/File:Schneebergerhof_01.jpghttps://en.wikipedia.org/wiki/Electric_power_transmission#/media/File:Qatar,_power_lines_(7).JPGhttps://commons.wikimedia.org/wiki/File:20._Station_der_Zukunftsenergientour-_Energieeffizienz-Projekte_SmartHome_in_Paderborn_(12100918353).jpg#filelinkshttps://www.flickr.com/photos/wfryer/1400456859
https://
commons.wikimedia.org/wiki/File:Applications-internet.svg
https://
commons.wikimedia.org/wiki/File:CSIRO_ScienceImage_3719_CSIROs_Fleck_wireless_sensor_network_technology.jpg
https://commons.wikimedia.org/wiki/File:FCS-Network.png
https
://www.flickr.com/photos/eurosporttuning/http://www.ladyada.net/make/midisense/distancesensors.htmlhttps://en.wikipedia.org/wiki/Rotary_actuator#/media/File:Micro_servo.jpghttp://www.hybridcars.com/wireless-brake-light-tested-by-ford