architectures for cyber-physical systems, or why ivan doesn’t want to graduate

Architectures for Cyber-Physical Systems,or Why Ivan Doesn’t Want to Graduate

Ivan Ruchkin1

Institute for Software ResearchCarnegie Mellon University

March 25, 2013

1In collaboration with A. Bhave, A. Rajhans, B. Krogh, D. Garlan, B. Schmerl, A. Platzer, S. Mitsch, andothers

1 / 40

Outline

1 Cyber-Physical Systems: Faces of EngineeringProblem and Hypothesis

2 Architecture for CPS ModelingStructural Consistency: QuadrotorOrganizing Verification Information: Collision Avoidance

3 Future Research Ideas

4 Conclusion

2 / 40

Cyber-Physical Systems: Faces of Engineering

Outline




4 Conclusion

3 / 40


Examples of CPS: Smart Cars

4 / 40


Examples of CPS: Air Traffic Control

5 / 40


Examples of CPS: Smart Buildings

6 / 40


Examples of CPS: Intelligent Highways

7 / 40


Examples of CPS: Smart Grid

8 / 40


Examples of CPS: Medical Devices

9 / 40


Examples of CPS: Spacecraft

10 / 40


Definition

Cyber-Physical Systems (CPSs) – systems with intensive interactionbetween computational and physical elements, often with a high degree ofuncertainty, autonomy, and openness2.

Unlike traditional control systems: variability in software andenvironments;Unlike purely software systems: physical concerns like sensing andmovement.

2R. Bahety and H. Gill, Cyber-Physical Systems. The Impact of Control Technology, IEEE, 2011.11 / 40


Definition


Unlike traditional control systems: variability in software andenvironments;

Unlike purely software systems: physical concerns like sensing andmovement.



Definition


Unlike traditional control systems: variability in software andenvironments;Unlike purely software systems: physical concerns like sensing andmovement.



Disciplines involved

Control theoryElectrical and electronic designArtificial intelligenceModeling and verificationSoftware programmingMechanical engineeringUbiquitous computing

As a result:Interdisciplinary teamsDifferent approaches to design

12 / 40


Technical Research Agenda in CPS

As declared3:Autonomy in varying operating conditions

Assurance: safety and securityInteroperability between different control systemsExtensibility in designApproaches to handle cyber AND physical concernsTools for design and development

3Lee, Edward A. Cyber Physical Systems: Design Challenges. EECS Department, University of California,Berkeley, January 2008.

13 / 40



As declared3:Autonomy in varying operating conditionsAssurance: safety and security

Interoperability between different control systemsExtensibility in designApproaches to handle cyber AND physical concernsTools for design and development


13 / 40



As declared3:Autonomy in varying operating conditionsAssurance: safety and securityInteroperability between different control systems

Extensibility in designApproaches to handle cyber AND physical concernsTools for design and development


13 / 40



As declared3:Autonomy in varying operating conditionsAssurance: safety and securityInteroperability between different control systemsExtensibility in design

Approaches to handle cyber AND physical concernsTools for design and development


13 / 40



As declared3:Autonomy in varying operating conditionsAssurance: safety and securityInteroperability between different control systemsExtensibility in designApproaches to handle cyber AND physical concerns

Tools for design and development


13 / 40



As declared3:Autonomy in varying operating conditionsAssurance: safety and securityInteroperability between different control systemsExtensibility in designApproaches to handle cyber AND physical concernsTools for design and development


13 / 40

Cyber-Physical Systems: Faces of Engineering Problem and Hypothesis

Outline




4 Conclusion

14 / 40


CPS Modeling: Problem 1/2

Use of a model in a CPS project:

Verification of a particular system property early in the lifecycleDocumentation and communicationConstraining downstream (model) implementation

Control algorithm: a generic form established through verification; aconcrete one is achieved through gradual refinement.

Supporting the assumptions of other modelsWorst-case assumptions on communication delays vs. detailedcalculations for delays.

15 / 40



Use of a model in a CPS project:Verification of a particular system property early in the lifecycle

Documentation and communicationConstraining downstream (model) implementation



15 / 40



Use of a model in a CPS project:Verification of a particular system property early in the lifecycleDocumentation and communication

Constraining downstream (model) implementationControl algorithm: a generic form established through verification; aconcrete one is achieved through gradual refinement.


15 / 40



Use of a model in a CPS project:Verification of a particular system property early in the lifecycleDocumentation and communicationConstraining downstream (model) implementation



15 / 40



Our interest lies in CPS modeling. Major challenge – heterogeneity ofmodels that comes from dissimilar modeling formalisms and makes thosehard to use together.

Discrete vs continuousSet-theoretic models vs. partial differential equations

physical vs. cyberForces and speeds vs. thread safety

Varying degree of determinismLTS vs. hybrid state automata

Varying levels of abstractionBasic element: “sensor” vs. “sensing error”.

Different treatment of system stateState machines vs. signal flow (Simulink)

Different treatment of timing, error handling, . . .

16 / 40


Research Hypothesis

Architecture can help alleviate the heterogeneity of CPS models and relateindividual ones.

Architecture has a good track record in software engineering as meansof aggregating analyses of different nature.Architecture is loose on semantics; strong semantics is one of thereasons it’s difficult to combine individual models.

17 / 40

Architecture for CPS Modeling

Outline




4 Conclusion

18 / 40

Architecture for CPS Modeling Structural Consistency: Quadrotor

Outline




4 Conclusion

19 / 40


Context

20 / 40


Context

21 / 40


Context

22 / 40


Problem

Inconsistent assumptions about connections of the GPS sensorControl model: the GPS is connected to the low-level processor.Hardware model: the GPS is connected to the high-level processor.

Solution: create architectural views for models and relate them.Outcome: the inconsistency detected during modeling, beforedevelopment.

23 / 40


Problem


Solution: create architectural views for models and relate them.

Outcome: the inconsistency detected during modeling, beforedevelopment.

23 / 40


Problem


Solution: create architectural views for models and relate them.Outcome: the inconsistency detected during modeling, beforedevelopment.

23 / 40


Solution: Method

View VX View VY

Base CPS Architecture

encapsulation/refinement

Model X Model Y

XVxR Y

VyR

VxBAR Vy

BAR

encapsulation

24 / 40


Solution: Control and Hardware Views

25 / 40


Solution: Base Architecture

26 / 40


Lessons

Architecture is great to relate models with explicit structuresBenefits: extensible specification of rules to find implicit defectsDownside: need to produce architectural views

27 / 40

Architecture for CPS Modeling Organizing Verification Information: Collision Avoidance

Outline




4 Conclusion

28 / 40


Context

Cooperative Collision Avoidance (CICAS):

X

Y

0l f

h

SV

POVZ0 0

g0

j

29 / 40


Problem

Safety is a complicated verification task for CICAS.Verification models need to be organized hierarchically

30 / 40


31 / 40


Architecture

POV SV Protocol

Verification M1 Verification M2

Base architecture

M11 M12 M13

M1

M0

M2

Structural mapping

Structural mapping

∧

∨

AQ

Model-to-view correspondence

AP

R1 R2

R11

R12R13

32 / 40


Lessons

Architecture as an information management framemorkBenefit: helps extend heterogeneous analysesDownside: high overhead of maintaining

33 / 40

Future Research Ideas

Outline




4 Conclusion

34 / 40


Generation of architectural views from models

Incorporating verification-significant information into architectureRepresenting assumptions as contstraints over view parametersUnderstanding the difference between model structure and model’sassumed architectureDevelopment of architecturally similar models helps reduce complexity

35 / 40


Generation of architectural views from modelsIncorporating verification-significant information into architecture

Representing assumptions as contstraints over view parametersUnderstanding the difference between model structure and model’sassumed architectureDevelopment of architecturally similar models helps reduce complexity

35 / 40


Generation of architectural views from modelsIncorporating verification-significant information into architectureRepresenting assumptions as contstraints over view parameters

Understanding the difference between model structure and model’sassumed architectureDevelopment of architecturally similar models helps reduce complexity

35 / 40


Generation of architectural views from modelsIncorporating verification-significant information into architectureRepresenting assumptions as contstraints over view parametersUnderstanding the difference between model structure and model’sassumed architecture

Development of architecturally similar models helps reduce complexity

35 / 40


Generation of architectural views from modelsIncorporating verification-significant information into architectureRepresenting assumptions as contstraints over view parametersUnderstanding the difference between model structure and model’sassumed architectureDevelopment of architecturally similar models helps reduce complexity

35 / 40

Conclusion

Outline




4 Conclusion

36 / 40

Conclusion

Summary

CPS present multiple challenges in heterogeneous modelingCombining physical and cyber aspectsRelating models of very different nature

Architecture may play different roles to bridge the gapPlenty of other reseach opportunities exist

37 / 40

Conclusion

Why Ivan does NOT want to graduate?

38 / 40

Conclusion

Thank you for your attention!

39 / 40

Conclusion

References

Bhave, A., B.H. Krogh, D. Garlan, and B. Schmerl. âĂĲViewConsistency in Architectures for Cyber-Physical Systems.âĂİ In 2011IEEE/ACM International Conference on Cyber-Physical Systems(ICCPS), 151 âĂŞ160, 2011.Rajhans, Akshay, and Bruce H. Krogh. âĂĲHeterogeneousVerification of Cyber-physical Systems Using Behavior Relations.âĂİIn Proceedings of the 15th ACM International Conference on HybridSystems: Computation and Control, 35âĂŞ44. HSCC âĂŹ12. NewYork, NY, USA: ACM, 2012.

40 / 40