Embed Size (px)
Citation preview
Embedded Real Time Systems
Prof. Davide Brugali
Università degli Studi di Bergamo
System development
Developing a dog house
2 LUCIA 2016, Orebro, December 16, 2016
Can be built by one person
Requires
Minimal modeling
Simple process
Simple tools
Developing a manor house
3 LUCIA 2016, Orebro, December 16, 2016
Built most efficiently and timely by a team
Requires
Extensive Modeling
Well-defined process
Powerful tools
Software development process
Given a system and a related problem,
before designing any software it is very
crucial to understand:
the physics of the system
the relation of variables
the user needs
the control objectives
Problem understanding
Requirements analysis
Requirements
There are different types of requirements :
User requirements (written for customers)
Statements in natural language plus diagrams of the
services the system provides
System requirements (contract for client and contractor)
A structured document setting out detailed descriptions of
the system services.
Software specification (written for developers)
A detailed software description that serves as a basis for
design and implementation.
System Requirements
Requirements should be :
Complete
Including the description of all the system services.
Consistent
There should be no conflicts or contradictions in the
descriptions of the various system facilities.
System Requirements
Requirements should be :
Complete
Including the description of all the system services.
Consistent
There should be no conflicts or contradictions in the
descriptions of the various system facilities.
Functional requirements
Autonomous Robots
Shop Floor logistics Autonomous cars
Tourist guide Store inventory
Mobile Robot Navigation
A
B
Motor control
Localization
Localization
Motor control
Functionalities
Motor control
Obstacle Avoidance
Localization
Trajectory following
Motion planning
Non-Functional requirements Functional requirements specify the expected behaviour of a
system, while non-functional requirements specify criteria
to evaluate the quality of the system behaviour.
Non-functional requirements define system properties (aka
quality attributes) and constraints on the services or functions
offered by the system.
• Examples of properties are performance, availability,
reliability, safety.
• Examples of constraints: timing, throughput, energy,
temperature, memory, weight, space, etc.
Non Functional Requirements
Shop Floor logistics
Store inventory
Autonomous cars
Tourist guide
Performance
The amount of useful work accomplished by a
computer system
Measures:
• Response time,
• Throughput,
• Accuracy
Usually with probabilities, confidence interval
Reliability, Availability, and Maintainability (RAM properties)
Reliability:
The probability that a system, including all hardware,
firmware, and software, will satisfactorily perform the task for
which it was designed or intended, for a specified time and in
a specified environment.
Maintainability
The probability that a system or system element can be
repaired in a defined environment within a specified period of
time.
Availability
The probability that a repairable system or system element is
operational at a given point in time under a given set of
environmental conditions.
Faults, errors, failures
Fault (often referred to as Bug)
A static defect in software (incorrect lines of code)
Error
An incorrect internal state (unobserved)
Failure
External, incorrect behaviour with respect to the
expected behaviour (observed)
Faults, errors, failures
Design fault Erroneous state
Failure
https://ece.uwaterloo.ca/~agurfink/ece653/assets/pdf/W01P2-FaultErrorFailure.pdf
Addressing Faults at Different Stages
https://ece.uwaterloo.ca/~agurfink/ece653/assets/pdf/W01P2-FaultErrorFailure.pdf
Safe navigation
Measured distance
blind
distance
braking
distance
Sensor range
Rover speed
Rover speed
&
Sensor scan rate
reaction
distance
Rover speed
&
Software System
Response Time
blind_distance + reaction_distance + bracking_distance < measured_distance
Embedded Real Time Systems
Prof. Davide Brugali
Università degli Studi di Bergamo
Software Design
Slide from the course of Real Time Systems by Giusepe Lipari, SSSA
Software development process
Slide from the course of Real Time Systems by Giusepe Lipari, SSSA
Software Design
Slide from the course of Real Time Systems by Giusepe Lipari, SSSA
Top-down approach
Slide from the course of Real Time Systems by Giusepe Lipari, SSSA
Bottom-up approach
Slide from the course of Real Time Systems by Giusepe Lipari, SSSA
Pro and cons
Slide from the course of Real Time Systems by Giusepe Lipari, SSSA
Embedded Real Time Systems
Prof. Davide Brugali
Università degli Studi di Bergamo
Software Variability Management
Slides from the course of Real Time Systems by Giusepe Lipari, SSSA
Variability in Mobile Robot Navigation Systems
A
B
Motor control
Localization
Localization
Motor control
Software variability
Motor control
Obstacle Avoidance
Localization
Trajectory following
Motion planning
A software component is a unit of composition
with contractually specified interfaces and explicit
context dependencies only.
A software component can be deployed
independently and is subject to composition by
third parties.
Components and Architectures
• Is it possible to build systems out of independently developed components?
Courtesy of http://ramsplus.com/services/
Components and Architectures
• Or should someone imagine how they will fit together in future applications?
Courtesy http://www.gobeyondthecube.com/
Traditional software development process
∞ Possible systems
Requirements specification
Architecture design and analysis
Components design / reuse
Code implementation / refactoring
Running code
System Deployment
Available technologies, user needs
Problems and Challenges ∞
Possible systems
Requirements specification
Architecture design and analysis
Components design
Code implementation
Running code
System Deployment
Available technologies
• Software development requires advanced skills in several technological domains
• Single application huge cost
• The Robotics domain is “affected” by a huge technological and software variability
• Single application short life
Software Product Lines ∞
Possible systems
Running code
Domain Analysis
Architecture design and analysis
Components design
Code implementation
System Deployment
Requirements specification
Product Derivation
Available technologies
DE
AE
Domain analysis
Warehouse logistics Hospital logistics Store inventory
Robot butler Vineyard monitoring
Product Line Engineering
Packages
Parking assistance package
Sport package
Rear view camera
Components Integration structure
Functionality specification
Products
Forces in Robot Control Architectures
Architecture
Forces in Robot Control Architectures
Perception Planning
Control
Architecture
functional
requirements
Forces in Robot Control Architectures
Perception Planning
Control
Architecture
Safety
Reliability
Availability
Maintainability
system
requirements
functional
requirements
Forces in Robot Control Architectures
Perception Planning
Control
Architecture
Safety
Reliability
Availability
Maintainability Flexibility
Openness
D.E.RT
Reusability
software
requirements
functional
requirements
system
requirements
Product Line Engineering
Packages
Parking assistance package
Sport package
Rear view camera
ntegration structure Functionality specification Variability Model Architectural Model
A repository of reusable
software components
Component
F
Component
F
youBot
Hardware
Driver
Component
F
Component
F
DWA
Obstacle
Avoidance
Component
F
Component
F
RTT
Motion
Planner
Products
A variety of
configured systems
Product Line Engineering
Packages
Parking assistance package
Sport package
Rear view camera
ntegration structure Functionality specification Variability Model Architectural Model
A repository of reusable
software components
Component
F
Component
F
youBot
Hardware
Driver
Component
F
Component
F
DWA
Obstacle
Avoidance
Component
F
Component
F
RTT
Motion
Planner
Products
A variety of
configured systems
Configuring the software control systems
Task
variability
Environment variability
Logistics
Inspection
Exploration
Guidance
indoor / outdoor
structured /unstructured
static / dynamic
Equipment
variability Software
variability
Functional Domain Analysis
Functional Requirements Specification
Resources Requirements Specification
Scenario Requirements Specification
Model-to-Model Transformation
M2M
Transformations
DWA
Software Product Lines ∞
Possible systems
Running code
Domain Analysis
Architecture design and analysis
Components design
Code implementation
System Deployment
Requirements specification
Product Derivation
Available technologies
DE
AE
Dynamic Software Product Lines ∞
Possible systems
Running code
Domain Analysis
Architecture design and analysis
Components design
Code implementation
System Deployment
Requirements specification
Product Derivation
Available technologies
DE
AE
Runtime Reconfiguration CE
Runtime reconfiguration
