/
Interfaces in Evolving  Cyber-Physical Interfaces in Evolving  Cyber-Physical

Interfaces in Evolving Cyber-Physical - PowerPoint Presentation

rivernescafe
rivernescafe . @rivernescafe
Follow
346 views
Uploaded On 2020-08-28

Interfaces in Evolving Cyber-Physical - PPT Presentation

Systems of Systems CPSoSs Bernhard Fr ömel lt froemelvmarstuwienacat gt Institute of Computer Engineering Vienna University of Technology Outline Introduction and Objectives ID: 808477

interface cpsos physical service cpsos interface service physical css cyber rui systems evolution environment system interactions itom layer time

Share:

Link:

Embed:

Download Presentation from below link

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.


Presentation Transcript

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

Slide2

OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion

Slide3

IntroductionChanging 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!

Slide4

CPSoS 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

Slide5

Systems-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 [..]

Slide6

Interfaces 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

Slide7

ObjectivesConceptualize 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

Slide8

OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion

Slide9

Architectural 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

Slide10

Architectural 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

Slide11

Architectural 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

Slide12

Architectural 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

Slide13

Architectural 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

Slide14

Architectural 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]

Slide15

Architectural 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

Slide16

Concept 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

Slide17

OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion

Slide18

Interface 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

Slide19

Cyber-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)

Slide20

Physical 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

Slide21

From 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

Slide22

Message/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

Slide23

Informational 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

Slide24

Example: 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

Slide25

Direct 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

Slide26

Service 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

Slide27

Service 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

Slide28

OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion

Slide29

Interfaces 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

Slide30

RUI 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).

Slide31

Roles 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

Slide32

Interface 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

Slide33

RUI at the Cyber-Physical Layer

Slide34

RUI 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

Slide35

RUI 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

Slide36

RUI 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)

Slide37

Connected 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

Slide38

Connected RUS Interface Layers, ExampleCyber-Physical Layer

Slide39

Cyber-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

Slide40

Connected RUS Interface Layers, ExampleInformational Layer

Slide41

All 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

Slide42

Connected RUS Interface Layers, ExampleService Layer

Slide43

4 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

Slide44

Execution 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 itselfNeed 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

Slide45

Frame-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!

Slide46

Frame-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

Slide47

RUIs 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

Slide48

OutlineIntroduction and ObjectivesArchitectural Elements of CPSoSsInterface LayersRelied Upon Interface (RUI)Handling Evolution at RUIsConclusion

Slide49

Interfaces 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]

Slide50

Unmanaged 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

Slide51

Scope 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

Slide52

Local 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

Slide53

Tree-like Search towards AdaptionVertices represent specific evolutionary states/versions of CSsEdges represent evolutionary steps

Slide54

Tree-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)

Slide55

Tree-like Search towards AdaptionSome versions of CSs are compatible at the presentIndicated compatible versions with upper and lower lassos

Slide56

Tree-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.

Slide57

Tree-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.

Slide58

SoS 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

Slide59

Management 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

Slide60

Assessing 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

Slide61

Handling 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)

Slide62

Avoiding 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

Slide63

Mitigation 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

Slide64

Detecting 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

Slide65

Self-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.

Slide66

ConclusionDiscussed 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

Slide67

ConclusionDiscussed 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

Slide68

Some 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

.

Slide69

Some 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.

Slide70

Image/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