Building Blocks of
Cyber Physical
Systems
Introduction
Course structure
Pandit Deendayal Petroleum University School of Technology
20ECE306T Building Blocks of Cyber Physical Systems 20ECE306
T
Teaching Scheme Examination Scheme Teaching
Scheme
L T P C Hrs/Week Theory Practical Total L
Marks
MS ES IA LW LE/Viva
3 0 0 3 3 25 50 25 -- -- 100 3
Time table
CURRICULAM
Lesson Plan
Week Topic Taught Remarks
1-4 Introduction and modeling of CPS Unit 1
5-8 Embedded system components for CPS Unit 2
9-12 Analysis of CPS Unit 3
13-16 CPS Simulations and case studies Unit 4
References
• Edward A. Lee and Sanjit A. Seshia, "Introduction to Embedded
Systems, A Cyber-Physical Systems Approach", Second Edition, MIT
Press, ISBN 978-0-262-53381-2, 2017, available for download.
• Derek Molloy, "Exploring Raspberry Pi: Interfacing to the Real
World with Embedded Linux", 2016, Wiley.
• Rajeev Alur, "Principles of Cyber-Physical Systems", 2015, MIT
Press.ISBN: 9780262029117
• Danda B. Rawat, Joel J.P.C. Rodrigues, Ivan Stojmenovic, "Cyber-
Physical Systems: From Theory to Practice", 2015, CRC Press.
Course Objectives
To learn the fundamentals of cyber physical systems.
To understand concepts of cyber physical system modelling.
To explore a wide range of engineering solutions using cyber
physical systems.
To implement applications of CPS.
Course Outcomes (CO’s)
• CO1- Remember different modeling, design, analysis
techniques of CPS.
• CO2- Understand methodology to execute different real
world scenarios using CPS.
• CO3- Apply modeling, simulation concepts to existing
problems.
• CO4- Analyse CPS parameters for the problem.
• CO5- Evaluate different CPS models for the problem.
• CO6-Create CPS simulation for real world problems.
Office Hour
• This is reserved time slot for students by faculty
• Faculty will make sure to remain in cabin during this time slot for the
session
• Fridayday 03.00 pm -04.00 pm
• Purpose
Email:
• Doubt clearing
[email protected] • One to one interactions Contact No.: 07923275459
Cabin Location
Room No. 208 – Faculty Wing, 2nd Floor, E Block, School of Technology
Introduction to CPS
A cyber-physical system (CPS) is an integration of
computation with physical processes whose behavior is defined
by both cyber and physical parts of the system.
Embedded computers and networks monitor and control the
physical processes, usually with feedback loops where physical
processes affect computations and vice versa.
As an intellectual challenge, CPS is about the intersection, not
the union, of the physical and the cyber.
It is not sufficient to separately understand the physical
components and the computational components. We must
instead understand their interaction.
Applications
Example 1.1: Heart surgery
Often requires stopping the heart, performing the surgery, and then restarting
the heart - extremely risky, many detrimental side effects.
A number of research teams have been working on an alternative where a
surgeon can operate on a beating heart rather than stopping the heart. There
are two key ideas that make this possible.
• First, surgical tools, robotically controlled so that they move with the motion of
the heart (Kremen, 2008). A surgeon can therefore use a tool to apply
constant pressure to a point on the heart while the heart continues to beat.
• Second, a stereoscopic video system can present to the surgeon a video
illusion of a still heart (Rice, 2008). To the surgeon, it looks as if the heart has
been stopped, while in reality, the heart continues to beat.
To realize such a surgical system requires:
• Extensive modeling of the heart, tools, computational hardware, and
software.
• Careful design of the software that ensures precise timing and safe fallback
behaviors to handle malfunctions.
• Detailed analysis of the models and designs to provide high confidence.
Applications
Example 1.2: Self Operating Cars
• Consider a city where traffic lights and cars cooperate to ensure
efficient flow of traffic.
• In particular, imagine never having to stop at a red light unless
there is actual cross traffic.
• Such a system could be realized with expensive infrastructure that
detects cars on the road.
• But a better approach might be to have the cars themselves
cooperate. They track their position and communicate to
cooperatively use shared resources such as intersections.
• Making such a system reliable, of course, is essential to its viability.
Failures could be disastrous.
About the Term “Cyber-
Physical Systems”
The term “cyber-physical systems” emerged in 2006,
coined by Helen Gill at the National Science Foundation in
the US.
• The term CPS relates to the currently popular terms Internet of Things (IoT),
Industry 4.0, the Industrial Internet, Machine-to-Machine (M2M), the
Internet of Everything, TSensors (trillion sensors), and the Fog (like the Cloud,
but closer to the ground). All of these reflect a vision of a technology that
deeply connects our physical world with our information world.
• The term CPS is more foundational and durable than all of these, because it
does not directly reference either implementation approaches (e.g., the
“Internet” in IoT) nor particular applications (e.g., “Industry” in Industry 4.0).
It focuses instead on the fundamental intellectual problem of conjoining the
engineering traditions of the cyber and the physical worlds.
Structure of CPS
Parts of The Structure
There are three main parts in the structure.
1. First, the physical plant is the “physical” part of a cyber-
physical system. It is simply that part of the system that is not
realized with computers or digital networks. It can include
mechanical parts, biological or chemical processes, or human
operators.
2. Second, there are one or more computational platforms, which
consist of sensors, actuators, one or more computers, and
(possibly) one or more operating systems.
3. Third, there is a network fabric, which provides the
mechanisms for the computers to communicate. Together, the
platforms and the network fabric form the “cyber” part of the
cyber-physical system.
Platforms
• There are Two networked
platforms each with its own
sensors and/or actuators.
• The action taken by the actuators
affects the data provided by the
sensors through the physical plant.
• Platform 2 controls the physical
plant via Actuator 1. It measures
the processes in the physical plant
using Sensor 2.
Computation 2
Implements a control law, which determines based on the sensor data what
commands to issue to the actuator. Such a loop is called a feedback control
loop. Platform 1 makes additional measurements using Sensor 1, and sends
messages to Platform 2 via the network fabric.
Computation 3
Realizes an additional control law, which is merged with that of Computation
2, possibly preempting it.
Example
Consider a high-speed printing press for a print-on-demand service. This
might be structured similarly to Figure 1.1, but with many more
platforms, sensors, and actuators.
• The actuators may control motors that drive paper through the press
and ink onto the paper.
• The control laws may include a strategy for compensating for paper
stretch, which will typically depend on the type of paper, the
temperature, and the humidity.
• A networked structure like that in Figure 1.1 might be used to induce
rapid shutdown to prevent damage to the equipment in case of paper
jams.
• Such shutdowns need to be tightly orchestrated across the entire
system to prevent disasters.
• Similar situations are found in high-end instrumentation systems and
in energy production and distribution (Eidson et al., 2009).
Motivating Example
• The specific application of a cyber-physical system is
the Stanford testbed of autonomous rotorcraft for
multi agent control (STARMAC), developed by Claire
Tomlin and colleagues as a cooperative effort at
Stanford and Berkeley (Hoffmann et al., 2004).
• The STARMAC is a small quadrotor aircraft. Its
primary purpose is to serve as a testbed for
experimenting with multi-vehicle autonomous
control techniques. The objective is to be able to
have multiple vehicles cooperate on a common task.
Figure 1.2: The STARMAC quadrotor aircraft in
flight (reproduced with permission).
Challenges
There are considerable challenges in making such a system
work.
First, controlling the vehicle is not trivial.
• The main actuators are the four rotors, which produce a
variable amount of downward thrust.
• By balancing the thrust from the four rotors, the vehicle can
take off, land, turn, and even flip in the air.
How do we determine what thrust to apply?
• Sophisticated control algorithms are required.
Challenges
Second, the weight of the vehicle is a major consideration.
• The heavier it is, the more stored energy it needs to carry,
which of course makes it even heavier.
• The heavier it is, the more thrust it needs to fly, which
implies bigger and more powerful motors and rotors.
• The design crosses a major threshold when the vehicle is
heavy enough that the rotors become dangerous to
humans.
• Even with a relatively light vehicle, safety is a considerable
concern, and the system needs to be designed with fault
handling.
Challenges
Third, the vehicle needs to operate in a context, interacting with its
environment.
• It might, for example, be under the continuous control of a watchful
human who operates it by remote control. Or it might be expected to
operate autonomously, to take off, perform some mission, return, and
land.
• Autonomous operation is enormously complex and challenging because it
cannot benefit from the watchful human.
• Autonomous operation demands more sophisticated sensors. The vehicle
needs to keep track of where it is (it needs to perform localization). It
needs to sense obstacles, and it needs to know where the ground is.
• With good design, it is even possible for such vehicles to autonomously
land on the pitching deck of a ship.
• The vehicle also needs to continuously monitor its own health, to detect
malfunctions and react to them so as to contain the damage.
The Design Process
• Modeling is the process of gaining a
deeper understanding of a system
through imitation. Models imitate the
system and reflect properties of the
system. Models specify what a
system does.
• Design is the structured creation of
artifacts. It specifies how a system
does what it does.
• Analysis is the process of gaining a
deeper understanding of a system
through dissection. It specifies why a
system does what it does (or fails to
do what a model says it should do). Figure 1.3: Creating embedded
systems requires an iterative process
of modeling, design, and analysis.
The Design Process
• The three parts of the process overlap, and
the design process iteratively moves among
the three parts.
• Normally, the process will begin with
modeling, where the goal is to understand
the problem and to develop solution
strategies.
• The process may progress quickly to the
design phase, where we begin selecting
components and putting them together
(motors, batteries, sensors, microprocessors,
memory systems, operating systems,
wireless networks, etc.).
• An initial prototype may reveal flaws in the
models, causing a return to the modeling
phase and revision of the models.
Figure 1.4: The STARMAC architecture
(reproduced with permission).
Hardware Architecture
• At the left and bottom of the figure are a number of sensors
used by the vehicle to determine where it is (localization)
and what is around it.
• In the middle are three boxes showing three distinct
microprocessors.
• The Robostix is an Atmel AVR 8-bit microcontroller that runs
with no operating system and performs the low-level control
algorithms to keep the craft flying.
• The other two processors perform higher-level tasks with
the help of an operating system.
• Both processors include wireless links that can be used by
cooperating vehicles and ground controllers.
Modeling
• A physical system is one realized in matter, in contrast to a
conceptual or logical system such as software and algorithms.
• The dynamics of a system is its evolution in time: how its state
changes.
• A model of a physical system is a description of certain aspects of
the system that is intended to yield insight into properties of the
system.
• Here, models have mathematical properties that enable
systematic analysis.
• The model imitates properties of the system, and hence yields
insight into that system.
CPS Models
• A cyber-physical system (CPS) is a system composed of
physical subsystems together with computing and
networking.
• The models will typically need to represent both dynamics
and static properties (those that do not change during the
operation of the system).
• It is important to note that a model of a cyber-physical
system need not have both discrete and continuous parts.
• It is possible for a purely discrete (or purely continuous)
model to have high fidelity for the properties of interest.
Design and Analysis
• Every system must be designed to meet certain
requirements.
• For embedded systems, which are often intended for use in
safety-critical, everyday applications, it is essential to certify
that the system meets its requirements. Such system
requirements are also called properties or specifications.
The need for specifications is aptly captured by the following
quotation, paraphrased from Young et al. (1985):
“A design without specifications cannot be right or wrong, it
can only be surprising!”
Summary
• Cyber-physical systems are heterogeneous
blends by nature.
• They combine computation, communication,
and physical dynamics.
• They are harder to model, harder to design, and
harder to analyze than homogeneous systems.
Modeling Dynamic
Behaviors
• Continuous Dynamics
1. Newtonian Mechanics
2. Actor Models
3. Properties of Systems
i. Causal Systems
ii. Memory-less Systems
iii. Linearity and Time Invariance
iv. Stability
4. Feedback Control
• Discrete Dynamics
• Hybrid Systems
• Composition of State Machines
• Concurrent Models of Computation
Continuous Dynamics
Newtonian Mechanics, Actor Models, Properties of
Systems, Feedback Control
Newtonian Mechanics
Newtonian Mechanics
Newtonian Mechanics
Velocity is the integral of acceleration, given by
Newtonian Mechanics
Newtonian Mechanics
Newtonian Mechanics
Newtonian Mechanics
• A helicopter has two rotors, one
above, which provides lift, and
one on the tail. Without the rotor
on the tail, the body of the
helicopter would spin.
• The rotor on the tail counteracts
that spin. Specifically, the force
produced by the tail rotor must
counter the torque produced by
the main rotor.
• Here we consider this role of the
tail rotor independently from all
other motion of the helicopter.
Now, we assume that the helicopter position is fixed at the origin,
so there is no need to consider equations describing position.
Moreover, we assume that the helicopter remains vertical, so pitch
and roll are fixed at zero.
Newtonian Mechanics
• With these assumptions, the
moment of inertia reduces to
a scalar that represents a
torque that resists changes in
yaw.
• The changes in yaw will be due
to Newton’s third law, the
action-reaction law, which
states that every action has an
equal and opposite reaction.
• This will tend to cause the
helicopter to rotate in the
opposite direction from the
rotor rotation.
• The tail rotor has the job of
countering that torque to keep
the body of the helicopter
from spinning.
Newtonian Mechanics
Actor Models
In particular, a continuous-time system (one that
operates on continuous-time signals) may be modeled
by a box with an input port and an output port as
follows:
Actor Models
Actor Models
Actor Models
Actor Models
Actor Models
Actor Models
Now, we will assume that the actor model captures everything of
interest about the system. This is an admittedly bold assumption.
Generally the properties of the actor model are only approximate
descriptions of the actual system.
Properties of Systems
Properties: Causal Systems
Properties of Systems
Properties of Systems
Properties: Linearity and Time Invariance
Properties of Systems
Feedback Control
Discrete Dynamics
1. Discrete Systems
2. The Notion of State
3. Finite-state Machines
3.1. Transitions
3.2. When A Reaction Occurs
3.3. Update Functions
3.4. Determinacy And Receptiveness
4. Extended State Machines
5. Nondeterminism
5.1 Formal Model
5.2 Uses of Nondeterminism
6. Behaviors And Traces
Discrete Systems
A discrete system operates in a sequence
of discrete steps and is said to have
discrete dynamics. Some systems are
inherently discrete.
Discrete Systems
The Notion of State
• Intuitively, the state of a system is its
condition at a particular point in time. In
general, the state affects how the system
reacts to inputs.
• Formally, we define the state to be an
encoding of everything about the past that
has an effect on the system’s reaction to
current or future inputs. The state is a
summary of the past.
The Notion of State
An Integrator operates in a time continuum. It integrates
a continuous-time input signal, generating as output at
each time the cumulative area under the curve given by
the input plus the initial state. Its state at any given time
is that accumulated area plus the initial state.
Finite-State Machines
A state machine is a model of a system with
discrete dynamics that at each reaction maps
valuations of the inputs to valuations of the
outputs, where the map may depend on its
current state. A finite-state machine (FSM) is a
state machine where the set States of possible
states is finite.
Finite-State Machines
If the number of states is reasonably small, then FSMs can be conveniently
drawn using a graphical notation like that in Figure 3.3. Here, each state is
represented by a bubble, so for this diagram, the set of states is given by
States = {State1, State2, State3}.
At the beginning of each sequence of reactions, there is an initial state, State1,
indicated in the diagram by a dangling arrow into it.
Finite-State Machines
When a Update Determinacy and
Transitions
Reaction Functions Receptiveness
Occurs
Transitions
Transitions
A guard is a predicate (a boolean-valued expression) that evaluates to
true when the transition should be taken, changing the state from that at
the beginning of the transition to that at the end. When a guard
evaluates to true we say that the transition is enabled. An action is an
assignment of values (or absent) to the output ports. Any output port not
mentioned in a transition that is taken is implicitly absent. If no action at
all is given, then all outputs are implicitly absent.
When a Reaction Occurs
• Nothing in the definition of a state machine constrains when it
reacts.
• When the environment determines that a state machine should
react, the inputs will have a valuation. The state machine will assign
a valuation to the output ports and (possibly) change to a new
state. If no guard on any transition out of the current state
evaluates to true, then the machine will remain in the same state.
• It is possible for all inputs to be absent at a reaction. Even in this
case, it may be possible for a guard to evaluate to true, in which
case a transition is taken.
• If the input is absent and no guard on any transition out of the
current state evaluates to true, then the machine will stutter. A
stuttering reaction is one where the inputs and outputs are all
absent and the machine does not change state. No progress is made
and nothing changes.
Update Functions
A finite-state machine is a five-tuple
The update function encodes all the transitions, guards, and output
specifications in an FSM. The term transition function is often used in
place of update function.
Determinacy and Receptiveness
FSM Model
FSM Model
FSM Model
Extended State Machines
The notation for FSMs becomes awkward when the number
of states gets large.
An extended state machine solves this problem by
augmenting the FSM model with variables that may be read
and written as part of taking a transition between states.
ESM VS FSM
First, variable declarations are
shown explicitly to make it easy
to determine whether an
identifier in a guard or action
refers to a variable or to an input
or an output.
Second, upon initialization,
variables that have been
declared may be initialized. The
initial value will be shown on the
transition that indicates the
initial state.
Third, transition annotations
now have the form
guard / output action
set action(s).
ESM Notation
• The guard and output action are the same as for standard FSMs, except they may
now refer to variables.
• The set actions are new. They specify assignments to variables that are made
when the transition is taken. These assignments are made after the guard has
been evaluated and the outputs have been produced.
• Thus, if the guard or output actions reference a variable, the value of the variable
is that before the assignment in the set action. If there is more than one set
action, then the assignments are made in sequence.
• Extended state machines can provide a convenient way to keep track of the
passage of time.
Nondeterminism
If for any state of a state machine, there are two distinct transitions with guards
that can evaluate to true in the same reaction, then the state machine is
nondeterministic. In a diagram for such a state machine, the transitions that
make the state machine nondeterministic may be colored red. In the example of
Figure 3.11, the transitions exiting state none are the ones that make the state
machine nondeterministic.
Formal Model
Uses of Nondeterminism
Environment Modeling: Most interesting state machines
react to inputs and produce outputs. These inputs must
come from somewhere, and the outputs must go
somewhere. We refer to this “somewhere” as the
environment of the state machine. It is often useful to hide
irrelevant details about how an environment operates,
resulting in a nondeterministic FSM model.
Uses of Nondeterminism
Specifications: System specifications impose requirements on some system
features, while leaving other features unconstrained. Nondeterminism is a useful
modeling technique in such settings as well. For example, consider a specification
that the traffic light cycles through red, green, yellow, in that order, without
regard for the timing between the outputs. The nondeterministic FSM in Figure
3.12 models this specification. The guard true on each transition indicates that
the transition can be taken at any step. Technically, it means that each transition
is enabled for any input valuation in Inputs.
Behaviors and Traces
• A behavior of a state machine is an assignment of such a
signal to each port such that the signal on any output port is
the output sequence produced for the given input signals.
• Deterministic state machines have the property that there is
exactly one behavior for each set of input sequences. That is,
if you know the input sequences, then the output sequence is
fully determined. That is, the machine is determinate. Such a
machine can be viewed as a function that maps input
sequences to output sequences.
• Nondeterministic state machines can have more than one
behavior sharing the same input sequences, and hence cannot
be viewed as a function mapping input sequences to output
sequences.
Behaviors and Traces
Behaviors and Traces
For a nondeterministic machine, it may be useful to represent all the possible traces
that correspond to a particular input sequence, or even all the possible traces that
result from all possible input sequences. This may be done using a computation tree.