2/24/2023

Lecture 3: CPS Requirements

Seyed-Hosein Attarzadeh-Niaki

Some Slides from Peter Marwedel and Philip Koopman

Embedded Real-Time Systems 1

Review
• CPS design: hardware and software
• CPS software development process
• Model-based design

Embedded Real-Time Systems 2

1
 2/24/2023

YOU ARE HERE

SPECIFY TRACEABILITY & VALIDATION ACCEPTANCE PRODUCT
PRODUCT Test Plan & TestResults TEST
Product SoftwareTest
Requirements Results

SPECIFY S OFTWARE
S OFTWARE Test Plan & TestResults TEST

SoftwareRequirements Integration TestResults

CREATE SW INTEGRATION
ARCHITECTURE Test Plan & TestResults TEST

High LevelDesign Unit TestResults

Test
DESIGN Plan & UNIT
M ODULES TEST
Test
Results
DetailedDesign SourceCode

IMPLEMENT

CPS & ES Requirements

• Functional and extra-functional requirements

Cyber-physical systems (!)

Embedded Real-Time Systems 4

2
 2/24/2023

Functional Requirements
Data collection requirements

• The observation of the RT entities in a controlled cluster and the

collection of these observations.

Direct digital control requirements

• Calculate the actuating variables for the actuators in order to control the
controlled object directly.

Man–machine interaction requirements

• A real-time computer system must

• inform the operator of the current state of the controlled object
• assist the operator in controlling the machine or plant object.

Embedded Real-Time Systems 5

Real-Time Requirements
• When Is a Computer System Real-Time?

• When the correctness of the system behavior

depends not only on the logical results of the
computations, but also on the physical time
when these results are produced.
– By system behavior we mean the sequence of
outputs in time of a system.

Embedded Real-Time Systems 6

3
 2/24/2023

Real-Time Constraints
• CPS must meet real-time constraints (deadlines)
• A real-time system must react to stimuli from the
controlled object (or the operator) within the time
interval dictated by the environment.
execute
t
• If a result has utility even after the deadline has passed, the deadline is
classified as soft;
• otherwise it is firm;
• If severe consequences could result if a firm deadline is missed, the
deadline is called hard.
➢ A guaranteed system response has to be explained without statistical arguments
[Kopetz, 1997].

Embedded Real-Time Systems 7

Four Types of Timing Specs Required

1. Measure elapsed time
Check, how much time has elapsed since last call
? execute
t
2. Means for delaying processes

t
3. Possibility to specify timeouts
Stay in a certain state a maximum time.

4. Methods for specifying deadlines

Not available or in separate control file. execute
t

Embedded Real-Time Systems 8

4
 2/24/2023

Efficiency Requirements
• CPS & ES must be efficient
– Code-size efficient
(especially for systems on a chip)

– Run-time efficient

– Weight efficient

– Cost efficient

– Energy efficient

Embedded Real-Time Systems 9

Importance of Energy Efficiency

Efficient software
design needed,
otherwise, the
price for software
flexibility cannot be
paid.

Embedded Real-Time Systems © Hugo De Man (IMEC) 10

Philips, 2007

5
 2/24/2023

Dependability Requirements
▪ CPS/ES must be dependable, in the sense of
•Reliability R(t) = probability of system working
correctly provided that is was working at t=0
•Maintainability M(d) = probability of system
working correctly d time units after error occurred.
•Availability: the fraction of time that the system
works
•Safety: no harm to be caused
•Security: confidential and authentic communication

Embedded Real-Time Systems 11

Security Requirements
Defending against
Cyber crime („Annual U.S. Cybercrime Costs Estimated
at $100 Billion; …[Wall Street Journal, 22.7.2013])
Cyber attacks ( Stuxnet)
Cyber terrorism
Cyber war
Connectivity increases threats
entire production chains can be affected
local islands provide some encapsulation, but contradict idea of
global connectedness
➢ Nowadays, we may have cyber-physical attacks.
➢ Integration with physical domain complicates the security
Embedded Real-Time Systems 12

6
 2/24/2023

Summary of
Extra-Functional Requirements
• Emergent properties (things hard to attribute to one
component)
– Performance, real-time deadlines
– Security, Safety, Dependability in general
– Size, Weight and Power consumption (“SWaP”)
• Often handled with an allocation budget across components
– Forbidden behaviors (“shall not do X”)
• Often in context of safety requirements
• “Safety function” is a way to ensure a negative behavior, but some
behaviors are emergent
• Design constraints
– Must meet a particular set of standards
– Must use a particular technology
– System cost, project deadline, project staffing

Embedded Real-Time Systems 13

Tiers of CPS Requirements

• Functional: Elevator shall deliver all passengers with reasonable speed
Marketing • Perhaps: Elevator shall be faster than competitor’s elevator
• Extra-functional: Elevator shall increase maintenance contract profits
Requirements • Constraint: “Product shall be compatible with building existing
maintenance networks”

• Functional: elevator shall have peak speed of 11.3 meters/sec (if fastest
Product competitor is 11.2 meters/sec)
• Extra-functional: elevator shall have a patented diagnostic interface
Requirements • Constraint: elevator shall be compatible with BACnet, but need not use it
for internal functions

Software • How do we build the software to get it done?

• For example, multi-tasking system with per-task functionality
• Functional: main motor shall use PID control with 10 msec loop rate
Requirements • Many requirements deal with the details

Embedded Real-Time Systems 14

7
 2/24/2023

Rules for Good CPS Software Requirements

Precise and minimally constrained

• Describes what system should do, not how it does it
• If possible has a numeric target instead of qualitative term
• Has tolerance (e.g., 500 msec +/- 10%, “less than X”)
Traceable & testable U1 R1 T1
• Each requirement has a unique label (e.g., “R-7.3”) U2 R2 T2
• Each requirement cleanly traces to an acceptance test U3 R3 T3
• Requirement satisfaction has a feasible yes/no test U4 R4 T4
U5 R5 T5
Supported within context of system
• Supported by rationale or commentary
• Uses consistent terminology
• Any conflicting requirements resolved or prioritized

Embedded Real-Time Systems 15

Examples of Problematic Requirements

Untraceable System shall shut down when E-STOP is activated.
(no label)

Untestable R-1.1: System shall never crash

Imprecise R-1.7: The system provides quick feedback to the user.

No measurement R-2.3: LED shall flash with a period of 500 msec

tolerance

Overly complex R-7.3: Pressing the red button shall activate Widget X, while pressing the blue button should
cause LED Z to blink instead of LED Y illuminating steadily, which would be accomplished via
the yellow button.

Describes R-8.3: Pressing button W shall cause two 16-bit integer values to be added, then …
implementation

Embedded Real-Time Systems 16

8
 2/24/2023

Example of Challenging Requirements:

Headlights On?
There was a highway department testing a new safety proposal. They asked motorists to turn on their
headlights as they drove through a tunnel. However, shortly after exiting the tunnel the motorists
encountered a scenic-view overlook. Many of them pulled off the road to look at the reflections of
wildflowers in pristine mountain streams and snow-covered mountain peaks 50 miles away. When the
motorists returned to their cars, they found that their car batteries were dead, because they had left
their headlights on.
- So, the highway department decided to erect signs to get the drivers to turn off their head-lights.
- First they tried: TURN YOUR LIGHTS OFF. But someone said that not everyone would heed the request
to turn their headlights on, and they couldn’t turn their headlights off.
- So they tried: IF YOUR HEADLIGHTS ARE ON TURN THEM OFF. But someone objected that would be
inappropriate if it were night time.
- So they tried: IF IT IS DAYTIME AND YOUR HEADLIGHTS ARE ON, THEN TURN THEM OFF. But someone
objected that would be inappropriate if it were overcast and visibility was greatly reduced.
- So they tried: IF YOUR HEADLIGHTS ARE ON AND THEY ARE NOT REQUIRED FOR VISIBILITY, THEN
TURN THEM OFF. But someone objected that many new cars are built so that their headlights are on
whenever the motor is running, so they couldn’t be turned off.
- So they tried: IF YOUR HEADLIGHTS ARE ON AND THEY ARE NOT REQUIRED FOR VISIBILITY, AND YOU
CAN TURN THEM OFF, THEN TURN THEM OFF. But someone objected....
- They decided to stop trying to identify applicable states – just alert the drivers and let them take
appropriate action. ARE YOUR LIGHTS ON?
• [Based on Gause and Weinberg, 1990]

Embedded Real-Time Systems 17

Example Process for

Embedded Requirements Creation
• Elicitation: Identify business/system requirements
– Customer provides requirements in request for quote (RFQ)
– Vendor may need to interview customer
– engineering judgment ( “guessing”)
• Create architecture: allocate functions to subsystems
– Class/Component diagram
– And interfaces
• Create scenarios/use cases
– High level flows through the system (flow chart)
– “building-block” use cases catching snippets of functionality
• Create detailed software requirements
– Behavioral requirements
– Constraints
Embedded Real-Time Systems 18

9
 2/24/2023

Requirements Approaches
Text document with list of requirements UML Use Case Diagram
• Works best if domain experts already know reqts.
• Over time, this can converge to better requirements.

UML Use Cases

• Different activities performed by actors
• Requirements are scenarios attached to each use case

Agile User Stories

• Each story describes a system interaction

Prototyping
• Customers know it when they see it
• Sometimes a paper mock-up is enough

Functional decomposition
• Start with primary system functions
• Make more and more detailed lists of sub-functions
(creates a “functional architecture”)

Embedded Real-Time Systems 19

Example Software Requirements

https://goo.gl/qct5tL
Embedded Real-Time Systems 20

10
 2/24/2023

IEEE Standard 830-1998

• “IEEE Recommended Practice for
Software Requirements • Outline
Specifications”
– “SRS” = Software requirements
specification
– In the embedded world, it should be
“System Requirements Specification”!

• Areas addressed
– Functionality (what does it do)
– External interfaces (this is really
architecture, but is important to have it
in SRS)
– Performance (speed, real-time issues)
– Attributes (non-functional requirements
such as maintainability, reliability)
– Design constraints (applicable
standards, policies, etc.)

Embedded Real-Time Systems 21

Example System:
Soda Vending Machine
• High Level Requirements: Make it
work like a real vending machine
• Simplification:
– Sodas cost some number of quarters
– All other coins are rejected (invisible
to your control system)
• Assume a Distributed System per
given diagram
– Processor for each button, coin
return controller, vending controller
– You get the message dictionary and
most of the requirements
specification (the “Architecture”)

Embedded Real-Time Systems 22

11
 2/24/2023

UML Use Cases

for Requirements Development
• Actor is a person Soda Machine
• Actor initiates a Use Case
U1. Customer
• Represents the system from inserts a quarter
the actor’s point of view
• Use cases are independent U2. Customer pushes a
(“transactions”) soda button

U3. Customer pushes

coin return button

Customer U4. Observe soda

availability U5. Collect
Money

U6. Refill
Machine Vendor

Embedded Real-Time Systems 23

System-Level Text Requirements

• Goal: implement a soda vending machine
– R1. Pushing a button shall vend a soda of the type corresponding to
that button.
– R2. The machine shall permanently retain exactly SODACOST coins for
each can of soda vended.
– R3. Coin return shall return all deposited coins since the last vend cycle.
– R4. The machine shall return all deposited money in excess of
SODACOST coins before a vend cycle.
– R5. The machine shall flash the light for a selected item while vending is
in progress to indicate acceptance of a selection to the buyer.
– R6. The machine shall illuminate the light for any out-of-stock item

• Assume a Fully Distributed System

– Processor for each button, coin return controller, vending controller

Embedded Real-Time Systems 24

12
 2/24/2023

Traceability: UML & Text Requirements

Text Requirements

Use Cases R1 R2 R3 R4 R5 R6
U1. Customer
inserts a quarter X
U2. Customer
pushes a soda X X
button
U3. Customer
pushes coin return X
button
U4. Observe soda
availability X
U5. Collect money X
U6. Refill machine X X
Embedded Real-Time Systems 25

Simulink Requirements

Embedded Real-Time Systems 26

13
 2/24/2023

Best Practices for Requirements

• Six C-terms for Good Requirements
– Clear, Concise, Correct, Coherent, Complete, and
Confirmable
• Also
– Deal with extra-functional issues
– Relate requirements to design flow
• E.g., associate with user stories or use cases
• Requirements pitfalls
– Avoid unnecessary details and implementation
– If it’s missing from requirements, it won’t get done
– If it’s not testable, you won’t know if it got done

Embedded Real-Time Systems 27

Next Lecture
• Models of computation
– Actor-based modeling
• Continuous Dynamics
– Causal systems
– Memoryless systems
– Linear time-invariant systems
• Read chapter 2 of LeeSeshia
• Review your knowledge from the “Signals &
Systems” course
Embedded Real-Time Systems 28

14