This document provides an overview of the Design of Software for Embedded Systems (SWES) course. It discusses the course organization, project requirements, and introduces some basic concepts and terminology related to embedded systems and real-time software. Specifically, it describes the challenges in embedded system design, different types of hardware platforms, characteristics of embedded software, issues related to timeliness and real-time scheduling, and how real-time operating systems address these issues. The document aims to equip students with foundational knowledge on embedded systems and real-time systems engineering.
1. ENTWURFVON SOFTWARE
FÜR EINGEBETTETE SYSTEME (SWES)
DESIGN OF SOFTWARE
FOR EMBEDDED SYSTEMS (SWES)
Dr. PeterTröger
Operating Systems Group,TU Chemnitz
2. PT 15/16
Design of Software for
Embedded Systems (SWES)
COURSE ORGANIZATION
• Weekly lectures (starting today) + tutorials (starting next week)
• 5 assignment sheets, minimum of 50% of all points needed
• OPAL: News, slides (after lecture !), discussion forum, time plans
• Written final exam
• Module 565050 (adopted from Dr. habil. D. Müller)
• Basic concepts and terminology
• Control theory for practitioners
• Programming for embedded systems in C and Ada
• Model-driven development for embedded systems, PLC systems
• Safety and security standards
2
3. PT 15/16
Design of Software for
Embedded Systems (SWES)
THE PROJECT
• 5 weeks of project work
• Work on a piece of embedded (real-time) software
• Targeting Raspberry PI with extension board, available in our lab
• Project results are submitted as assignment solutions
• Teams of 2 persons
• Q&A in tutorial sessions and OPAL forum
• First project-related task with assignment sheet 3 (mid-November)
• Submission system for both non-project and project assignments
• You hand-in either code or a PDF document —> DEMO
3
5. PT 15/16
Design of Software for
Embedded Systems (SWES)
EMBEDDED SYSTEM
• Computer system in a context
• Specific dedicated task (vs. all-purpose computer)
• Often hardware/software co-design
• Optimize design based on application characteristics
• Often non-visible for user
• Often real-time systems (max. response time ≤ deadline)
• High cost pressure - low memory size, simple CPUs
• Energy efficiency
• Everywhere: Cell phones, printer,s automobiles, aviation products,
household devices, medical devices, children toys, …
5
6. PT 15/16
Design of Software for
Embedded Systems (SWES)
EMBEDDED SYSTEMS
6
[http://didik.blog.undip.ac.id/]
7. PT 15/16
Design of Software for
Embedded Systems (SWES)
SOFTWARE FOR EMBEDDED SYSTEMS
• Ebert and Jones, 2009
• Worldwide market
of 160 billion €
• ~30 embedded
processors per
person in developed
countries
• 98% of all produced
microprocessors for
embedded
applications
7
8. PT 15/16
Design of Software for
Embedded Systems (SWES)
CHALLENGES
• How to minimize power consumption and costs ?
• Amount and type of hardware needed
• Power-aware software and operating systems
• How can you interact with the physical world ?
• Hardware sensors and actuators
• Real-time software constraints
• How to ensure non-functional properties ?
• 1990-2000: 40% of recalled pacemakers due to firmware errors
• New cars with > 20 electronic control units (ECU),
1GB of software in premium car
8
9. PT 15/16
Design of Software for
Embedded Systems (SWES)
PROBLEM AREAS
9
Hardware
Software
Non-functionalproperties
10. PT 15/16
Design of Software for
Embedded Systems (SWES)
HARDWARE
10
Desired functionality
General purpose Application-specific Single-purpose
11. PT 15/16
Design of Software for
Embedded Systems (SWES)
HARDWARE
11
General purpose Application-specific Single-purpose
[Vahid/Givargis]
12. PT 15/16
Design of Software for
Embedded Systems (SWES)
HARDWARE
• General-purpose hardware
• Main goal is flexible usage with best-possible performance
• Programmable for all use cases
• Application-specific hardware
• Programmable for restricted performance-optimized uses cases
• Examples:Video stream processing, audio encoding
• Single-purpose hardware
• Integrated circuit to perform exactly one task in the fastest way
• Not programmable, algorithms fixed in hardware
12
13. PT 15/16
Design of Software for
Embedded Systems (SWES)
FLEXIBLE OR EFFICIENT?
13
[Altera]
14. PT 15/16
Design of Software for
Embedded Systems (SWES)
HARDWARE
14
General purpose
Application-
specific
Single purpose
Programmable in Software Hardware Software -
Performance low medium medium high
Energy Efficiency low medium medium high
Feature
Flexibility
very high medium low very low
Per unit
price savings
low low medium very high
Example Microprocessor PLD / FPGA DSP ASIC / ASSP
15. PT 15/16
Design of Software for
Embedded Systems (SWES)
GENERAL PURPOSE CHIP
• Microprocessor: Multi-
purpose, programmable device
• Central Processing Units
(CPUs) + volatile memory + I/
O devices
15
[Stallings]
• Fetch instruction and execute it -
typically memory access,
computation, and / or I/O
• I/O devices and memory
controller may interrupt the
instruction processing
16. PT 15/16
Design of Software for
Embedded Systems (SWES)
GENERAL PURPOSE CHIP
• RISC - Reduced Instruction Set Computer
• MIPS,ARM, DEC Alpha, Sparc, IBM 801, Power, etc.
• Small number of instructions, few data types in hardware
• Instruction size constant, few addressing modes
• Relies on optimization in software
• CISC - Complex Instruction Set Computer
• VAX, Intel X86, IBM 360/370, etc.
• Large number of complex instructions, may take multiple cycles
• Variable length instructions, smaller code size
• Focus on optimization in hardware
• RISC designs lend themselves to exploitation of instruction level parallelism
16
17. PT 15/16
Design of Software for
Embedded Systems (SWES)
ARM
• ARM design started in 1983 by Acorn Computers Ltd. Roger Wilson and Steve Furber
• 1990 renamed to Advanced RISC Machines Ltd., 1998 renamed to ARM Ltd.
• 32-Bit and 64-Bit RISC processor architecture
• ARM does not manufacture itself, licenses to others:ATMEL, Intel, IBM, Nintendo, ...
• ARM targets low-power and low-cost embedded applications
17
[enterprisetech.com]
18. PT 15/16
Design of Software for
Embedded Systems (SWES)
GENERAL PURPOSE CHIP
• Programmable logic device
(PLD)
• Type of semiconductor
hardware that can be
„re-wired“ after production
18
[TyGaribay,Altera]
FPGA Design Cost 3.200.000 $
FPGA Starting Unit Price 4x375 $ = 1500 $
ASIC Design Cost 85.000.000 $
ASIC Starting Unit Price 400 $
ASIC market delay 3 months
Early entry device volume 49 %
Processor Blade Example [Xilink]
19. PT 15/16
Design of Software for
Embedded Systems (SWES)
GENERAL PURPOSE CHIP
• Field Programmable Gate Arrays (FPGA)
• Reconfigurable technology
• Hardware (!) functionality can be changed
• Errors can be corrected/masked
• Very short development times, suitable for low number of units
• Hardware description languages:VHDL andVerilog
• May be used to validate ASIC design
• SRAM- and Flash-based FPGAs allow reconfigurable computing
19
20. PT 15/16
Design of Software for
Embedded Systems (SWES)
APPLICATION-SPECIFIC CHIP
• Digital signal processor (DSP)
• Specialized microprocessor for digital processing of analogous signals
• A/D converter for input (e.g., camera), D/A converter for output
• Often fixed point arithmetics (faster)
• Real-time requirements (mostly soft RT), no multitasking
• Multimedia applications (image and audio processing)
• Cryptography
• Programmable in software
20
21. PT 15/16
Design of Software for
Embedded Systems (SWES)
SINGLE PURPOSE CHIP
• Application-specific
integrated circuit
(ASIC)
• Hardware device for
being used in one
product
• Application-specific
standard part
(ASSP)
• ASIC for re-use in
multiple products
(e.g. USB host
controller)
21
[xilink.com]
22. PT 15/16
Design of Software for
Embedded Systems (SWES)
MICROCONTROLLER
• Integrated circuit with processor, memory, and I/O hardware
(µC, uC, MCU)
• Example:Atmel AT89S8253 8-bit microcontroller
• MCS 51 instruction set
• 12 kByte Flash memory, 2 kByte EEPROM data memory
• 256 x 8 Bit internal RAM
• 32 programmable I/O lines
• UART serial port
• Three 16-bit timers
• 2.7V - 5.5V operating range
• Power saving mode
22
[mikroe.com]
23. PT 15/16
Design of Software for
Embedded Systems (SWES)
SYSTEM ON CHIP
• System on chip (SoC)
• Combines functional blocks (‚IP cores‘) in one large IC
• CPU, ROM, RAM, flash, Ethernet, Bluetooth, audio, USB, time,
voltage, …
• Soft-IP-Core in hardware description language (Verilog,VHDL)
• Can be parameterized (cache sizes, bus sizes, …),
see opencores.org
• Licensed by companies such as ARM and MIPS
• Hard-IP-Core already built or integrated in FPGA
• Replace multi-chip setup, reduces power and space demands
• Typically with debugging interface (JTAG, USB)
23
24. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE:APPLE IPHONE 6
24
[techinsights.com]
25. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE:APPLE IPHONE 6
25
[techinsights.com]
26. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE:APPLE IPHONE 6
26
[techinsights.com]
27. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE:APPLE A8 SOC
27
[www.anandtech.com]
28. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE: RASPBERRY PI
• Broadcom BCM2835 SoC
• ARM11 processor
• Videocore 4 GPU
• General purpose I/O
(GPIO) pins
• Audio, USB, HDMI, I2C,
UART
• Timers
• Interrupt controller
28
[raspberrypi.org]
29. PT 15/16
Design of Software for
Embedded Systems (SWES)
PROBLEM AREAS
29
Hardware
Software
Non-functionalproperties
30. PT 15/16
Design of Software for
Embedded Systems (SWES)
EMBEDDED SOFTWARE
• Embedded software interacts with the physical world
• Often written by domain experts, not computer scientists
• Timeliness becomes more important (e.g. deadlines)
• Concurrency becomes more important (e.g. physical events)
• Liveness becomes crucial (e.g. deadlock prevention)
• Heterogeneity becomes default
• In general: Predictable behavior, from nice-to-have to mission-critical
30
http://ptolemy.eecs.berkeley.edu/publications/papers/02/embsoft/embsoftwre.pdf
31. PT 15/16
Design of Software for
Embedded Systems (SWES)
Controlled Process
TYPICAL STRUCTURE
31
Sensors
Controller
Software
Clock
Operator
Environment
Actuators Display
32. PT 15/16
Design of Software for
Embedded Systems (SWES)
STARTING POINT
32
• Understanding of resources
• Describe resources available to the application (CPU, memory, OS)
• Driven by cost factors and environmental conditions
• Understanding of algorithms
• Which resources will be used in which way
• Relevant resulting performance metrics
• Understanding of workload
• Must consider control and data dependencies
• Driven by environmental conditions
• Describe tasks to be handled + timeliness constraints
33. PT 15/16
Design of Software for
Embedded Systems (SWES)
TIMELINESS
• Embedded systems are often real-time systems
• Hard real-time systems are often embedded systems
“A real-time system is one in which the correctness of the computations not
only depends on the logical correctness of the computation, but also on the
time at which the result is produced (deadline). If the timing constraints of
the system are not met, system failure is said to have occurred.”
• Autopilot in airplane vs. YouTube video player
• Position calculation vs. 30 images / s
• Do all tasks have to be executed before their deadline ?
• How to deal with missed deadlines ?
• When is the result produced ?
33
34. PT 15/16
Design of Software for
Embedded Systems (SWES)
REAL-TIME
• Hard real-time: Missing a deadline is not acceptable
• Aircraft control systems
• Nuclear power / chemical plant safety mechanisms
• Medical devices
• Soft real-time: Missing a deadline is undesirable
• Multimedia
• Airline reservation
• High-speed trading applications
• Real-time objectives may change during operation
• Example: Grounded airplane vs. flying airplane
34
35. PT 15/16
Design of Software for
Embedded Systems (SWES)
TASK /VALUE FUNCTIONS
35
Value
deadline
Value
deadline
Value
deadline
Value
deadline
Value
deadline
Value
deadline
Value
deadline
Value
deadline
Value
deadline
• Deadline missed
• Hard real-time:Task result
has no more value
• Soft real-time:Task result
has reduced value
36. PT 15/16
Design of Software for
Embedded Systems (SWES)
HARD REAL-TIME
36
Release
Time
Scheduling
Time
Completion
time
Absolute
Deadline
Execution Time
Relative Deadline
Zeitliche Parameter (Timing constraints) eines Jobs.
t
0
Response Time
37. PT 15/16
Design of Software for
Embedded Systems (SWES)
SOFT REAL-TIME
37
Release
Time
Scheduling
Time
Completion
time
t
0
Absolute
Deadline
Tardiness
Relative Deadline
Execution Time
Response Time
38. PT 15/16
Design of Software for
Embedded Systems (SWES)
REAL-TIMETASKS
• Periodic tasks
• Examples: Sensor data acquisition, action planning, system monitoring
• Must be regularly activated (once per period)
• Aperiodic tasks
• Example: Background services, logging, operator requests
• Triggered by well-known event at any time
• Sporadic tasks
• Example: Collision detection in a roboter, I/O device interrupt
• Aperiodic task with minimum inter-arrival time (rate restriction)
38
39. PT 15/16
Design of Software for
Embedded Systems (SWES)
REAL-TIME SCHEDULING
• Scheduling: Define order of task execution
• Mature theory for real-time schedules on uniprocessors since 1970’s
• Theory for real-time multiprocessor schedules still under research
• On small embedded systems (micro-controller scale)
• Only one / a few tasks
• ‚Manual‘ scheduling by developer good enough
• On larger embedded systems
• Real-time operating system
• Implements appropriate scheduling concepts
• Supports prioritization and synchronization of concurrent tasks
39
40. PT 15/16
Design of Software for
Embedded Systems (SWES)
REAL-TIME SCHEDULING
40
Real-Time Scheduling
Soft
Hard
Dynamic Static
Preemptive Non-Preemptive Preemptive Non-Preemptive
41.
42. PT 15/16
Design of Software for
Embedded Systems (SWES)
REAL-TIME SCHEDULING
• ‚Manual scheduling‘
• Simple round-robin implementation, based on polling
• Device C needs periodic attention,A and C are purely event-driven
42
Embedded
Operating Systems
HPI
Device A
(rain sensor)
Device B
(ABS)
Device C
(speed display)
43. PT 15/16
Design of Software for
Embedded Systems (SWES)
REAL-TIME SCHEDULING
• ‚Manual scheduling‘ with
round robin with
interrupts
43
8
Embedded
Operating Systems
HPI
Embedded
Operating Systems
HPI
void Task2(){
while(true){
// wait for signal Y
// handle device B
}
}
Round Robin Round Robin RTOS
• With support from
real-time operating
system
44. PT 15/16
Design of Software for
Embedded Systems (SWES)
REAL-TIME SCHEDULING
44
• Real-Time Operating System (RTOS) features
• Real-time scheduling with priorities
• Support for concurrency, preemption and prioritization
• Predictable timing behavior of interrupt routines and system calls
Embedded
Operating Systems
HPI
high priority
low priority
Round Robin Round Robin
with Interrupts
RTOS
all code
device A ISR
device B ISR
all other code
device A ISR
device B ISR
Task 1
Task 2
45. PT 15/16
Design of Software for
Embedded Systems (SWES)
PROBLEM AREAS
45
Hardware
Software
Non-functionalproperties
46. PT 15/16
Design of Software for
Embedded Systems (SWES)
DEPENDABILITY
• Umbrella term for operational requirements on a system
• Laprie: „ Trustworthiness of a computer system such that
reliance can be placed on the service it delivers to the user “
• Adds a third dimension to system quality
• General question: How to deal with unexpected events ?
46
47. PT 15/16
Design of Software for
Embedded Systems (SWES)
DEPENDABILITY IN EMBEDDED
• Critical application domains always considered dependability
• Aviation industry, power industry, military equipment, …
• But all embedded systems have actuators, people count on them
• Dangerous real-world interactions may be less explicit
• Examples: Heating devices, power / water supply devices
• Today more domain experts than software engineering experts
• New challenging through increasingly interconnected devices
• Internet of Things (IoT)
47
48. PT 15/16
Design of Software for
Embedded Systems (SWES)
DEPENDABILITYTREE [LAPRIE]
48
49. PT 15/16
Design of Software for
Embedded Systems (SWES)
THREATS
• System failure - ,Ausfall‘
• Event that occurs when the service no longer complies with the specification
/ deviates from the correct service.
• System error - ,Fehler(zustand)‘
• Part of system state that can lead to subsequent failure
• Some sources define errors as active faults - not in this course ...
• System fault - ,Fehler(ursache)‘
• Adjudged or hypothesized cause of an error
• Failure occurs when error state alters the provided service
• Systems are build from connected components, which are again systems
• Fault is the consequence of a failure of some other system to deliver its service
49
Fault
Error
Failure
50. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONSEQUENCES [KNIGHT]
• Human injury or loss of life
• Damage to the environment
• Damage to or loss of equipment
• Damage to or loss of data
• Financial loss by theft
• Financial loss through production of useless or defective products
• Financial loss through reduced capacity for production or service
• Loss of business reputation, customer base, or jobs
50
51. PT 15/16
Design of Software for
Embedded Systems (SWES)
FAULT MODEL
• Faults can be classified into categories on different abstraction levels
• Physics
• Circuit level / switching circuit level
• Interesting for hardware design research (not this course)
• Investigate logical signals on connections
• stuck-at-zero, stuck-at-one, bridging faults, stuck-open
• Register transfer level
• Processor-memory-switch (PMS) level
• Hardware system level
• ... (Software) ...
51
52. PT 15/16
Design of Software for
Embedded Systems (SWES)
FAILURETYPES
• Duration of the failure
• Permanent failures - no possibility for repairing or replacement
• Recoverable failures - back in operation after the system recovered from
error state
• Transient failures - short duration, no major recovery action
• Effect of the failure
• Functional failures - system does not operate according to its specification
• Performance failures - performance or SLA specifications not met
• Scope of the failure
• Partial failure - only parts of the system become unavailable
• Total failure - all services go down
52
53. PT 15/16
Design of Software for
Embedded Systems (SWES)
FAILURE SEVERITY
• Denotes consequences of failure
• Benign failures (,unkritische Ausfälle‘)
• Failure costs and operational benefits are similar
• Sometimes also umbrella term for failures only detected by inspection
• A system with only such failures is fail-safe
• Catastrophic failures (,kritische Ausfälle‘)
• Costs of failure consequences are much larger than service benefit
• Significant / serious failures - Intermediate steps expressing reduced service
• Grading of failure consequences on overall system depends on application
• Flying airplane - Catastrophic stopping failure,Train - Benign stopping failure
• Criticality - Highest severity of possible failure modes in the system
53
54. PT 15/16
Design of Software for
Embedded Systems (SWES)
ATTRIBUTES
• Reliability - Function R(t)
• Probability that a system is functioning properly and constantly over
time
• Assumes that system was fully operational at t=0
• Denotes failure-free interval of operation
• Availability - Statement if a system is operational at a point in time /
fraction of time
• Describe system behavior in presence of error treatment mechanisms
• Steady-state availability - Probability that a system will be
operational at any random point of time,
• Fraction of time a system is operational during its expected
lifetime: As = Uptime / Lifetime
54
55. PT 15/16
Design of Software for
Embedded Systems (SWES)
SAFETY
• Different levels of critical participation for a computer system
• Information provisioning to human controller on request
• Interpretation of data and presentation to the user
• Issues command on behalf of the human controller
• Replaces human controller
• Trend to realize critical systems with commercial-of-the-shelf
components
• Driven by budget cuts and performance advantage
• Puts sole responsibility on software layer, in contrast to early
hardware-only redundancy approaches
55
56. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE: DO-178D
• Software Considerations in Airborne Systems and Equipment Certification
• Mature document, developed for more than 20 years
• Definition of severity of failure for airplane, crew, and passengers
• Catastrophic - Loss of ability to continue safe flight and landing
• Major - Reduced airplane or crew capability to cope with operating
conditions
• Reduction in safety margins and functional capabilities
• Higher workload or physical distress for the crew
• Minor - Not significantly reduced airplane safety, slight increase in workload
(Example: Change of flight plan)
• No effect - Failure results in no loss of operational capabilities and no
increase in crew workload
56
57. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE: DO-178D
57
58. PT 15/16
Design of Software for
Embedded Systems (SWES)
SAFETYVS. SECURITY
• Different technical foundations, e.g. for recovery from errors
• Embedded system development may need to consider both aspects
58
Safety Security
Assumes trustworthy operators Assumes fault-free system
Assumes closed system Assumes open, connected system
Existing standards
(DO-178C, ISO26262, …)
Existing standards
(ISO 27002, Common Criteria, …)
59. PT 15/16
Design of Software for
Embedded Systems (SWES)
PROBLEMS AREAS
59
Hardware
Software
Non-functionalproperties
• Microprocessor
• CISC vs. RISC
• Microcontroller
• SoC
• ASIC vs. PLC
• ARM
• Real-Time
• Code-driven
• Model-driven
• Cross-Compile
• Control loops
• Dependability
• Safety
• Security
• Reliability
• Availability
61. PT 15/16
Design of Software for
Embedded Systems (SWES)
Controlled Process
EMBEDDED SYSTEM
61
Sensors
Controller
Software
Clock
Operator
Environment
Actuators Display
62. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONTROLTHEORY
• Create abstract models for a controlled process
• Typical challenge in ‚connected‘ embedded systems
• Focus on static and dynamic behavior
• Results in the behavioral design of a controller
• Abstraction from specific implementation details (e.g. car speed control)
creates a dedicated mathematical problem
• How to consider measured input to control some regulation output
• Mathematical principles as glue between engineering disciplines
• Everybody has some kind of ‚control problem‘
• Example: Control unit (Steuergerät) in automotive systems
62
63. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONTROLTHEORY
• Open loop / non-feedback control („Steuerung“)
• Controller activity based on current state
• Output of the controlled system is not observed
• External deviations must be considered at design-time
• Example: Power supply for electric motor with constant load
63
ï Example: Signal flow diagram of open loop and closed loop control
The block diagram symbols described above help illustrate the difference
between open loop and closed loop control processes clearly.
In the open action flow of open loop control (Fig. 7), the operator positions
the remote adjuster only with regard to the reference variable w. Adjustment
is carried out according to an assignment specification (e.g. a table: set point
w1 = remote adjuster position v1; w2 = v2; etc.) determined earlier.
⋅V74/DKE
Fig. 6: Branch point
xw
Fig. 7: Block diagram of manual open loop control
man
remote
adjuster system
control
valve
diagram
p control
64. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONTROLTHEORY
• Closed loop / feedback control („Regelung“)
• Feedback from system output used to adjust controller operation
• Error between output and reference used to adopt the operation
• System can react on external disturbances
• Instability can happen
64
In the closed action flow of closed loop control (Fig. 8), the controlled varia-
ble x is measured and fed back to the controller, in this case man. The con-
troller determines whether this variable assumes the desired value of the
reference variable w. When x and w differ from each other, the remote ad-
juster is being adjusted until both variables are equal.
Part
xw +
_
Fig. 8: Block diagram of manual closed loop control
man
remote
adjuster
control
valve
system
signal flow
of closed lo
65. PT 15/16
Design of Software for
Embedded Systems (SWES)
CLOSED LOOP CONTROL
65
Using the symbols and terminology defined above, Fig. 9 shows the typical
action diagram of a closed loop control system (abbreviations see page 10).
SAMSONAG⋅00/03
z
ew +
–
yr y x
r
Fig. 9: Block diagram of a control loop
controlling
element
measuring
equipment
controller
final
control
element
system
actuator
elements and
of a control l
• Regulatory control: Manage with respect to a reference value (w)
• Disturbance rejection: Eliminate effect of a disturbance (z)
• Optimization:Achieve the „best“ value of the outputs (x)
[SamsonAG]
66. PT 15/16
Design of Software for
Embedded Systems (SWES)
Sensor
Controller
System
CLOSED LOOP CONTROL
66
Disturbance
(d)
Controlled
Variable (y)
Measured
Output (yM)
Actuator
Actuating
Variable (uS)
Controller
Output (u)
Environment
Error /
Control deviation:
e=w-yM
Reference /
Set Point (w)
Symbols differ in German DIN notation and English notations!
67. PT 15/16
Design of Software for
Embedded Systems (SWES)
Sensor
Controller
System
DIGITAL CONTROLLER
67
Disturbance
(d)
Controlled
Variable (y)
Measured
Output (yM)
Actuator
Actuating
Variable (uS)
Controller
Output (u)
Environment
Error /
Control deviation:
e=w-yM
Reference /
Set Point (w)
A/D
D/A
Symbols differ in German DIN notation and English notations!
68. PT 15/16
Design of Software for
Embedded Systems (SWES)
CLOSED LOOP CONTROL
• Set point given by user, or higher-level system, or both
• Examples
• Biology: Upright walk, body temperature, eye adaption on light
• Home devices: Heating based on internal temperature sensor, fridges
• Industry:ABS in cars, power grid control, servo systems
• Time dependency of set point
• Constant set point: Fixed set point control
• Example: Boiler temperature control
• Varying set point: Follow-up control
• Example:Weather-compensated temperature control
68
69. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE
69
with the controlled variable and, in case of a control difference, the valve is further
opened or closed depending on polarity until the controlled variable and the reference
variable are equal again. The closed control loop is clearly identifiable, as the
corresponding block diagram also shows.
w x
T
1
2T
5
y
3 4
6
w
8
. 1 Temperature controller
. 2 Temperature sensor
. 3 Mixing valve
. 4 Circulation pump
. 5 Radiator
. 6 Boiler
Closed loop clearly identifiable
Valve is opened and closed to
bring controlled variable and
reference variable together
[Siemens]
70. PT 15/16
Design of Software for
Embedded Systems (SWES)
EXAMPLE
• 1 - Outside temperature sensor
• 2 - Heating curve setting
• 3 - Supply temperature sensor
• 4 - Supply temperature controller
• 5 - Control valve (actuator + control element)
• w - Supply temperature setpoint
(open-loop control variable 1)
• x1 - Supply temperature actual value
(closed-loop controlled variable)
• x2 - Room temperature actual value
(open-loop control variable 2)
• z1 - Interference variable 1(external heat gain)
• z2 - Interference variable 2 (fluctuating boiler water temperature)
• y - Manipulated variable
70
z1
x2
1
y 4
2
3
5
z2
x1
a b
d c
w
x2
z1 z2
B31-13
w
x
y
1
x2
[Siemens]
71. PT 15/16
Design of Software for
Embedded Systems (SWES)
VARIATIONS
• Disturbance feed-forward control
• Disturbance is directly used by controller, allows faster reaction
• Disturbance must be locatable and measurable
• Cascade control
• One controller feeding another one
• Robust control, adaptive control
• Modification of controller through self-feedback
• Example: Flying missile with decreasing fuel mass
71
72. PT 15/16
Design of Software for
Embedded Systems (SWES)
STABILITY
• Control loop is an oscillatory system
• Controlled and manipulated variable influence each other
• System therefore may escalate into instability
• Bounded input / bounded output (BIBO) stability
• Output signal should not grow indefinitely when the input is limited
• Mandatory condition for every serious control system
72
4.2.1 Response to interference
If, without external intervention, the controlled variable in the control loop fails to
assume a constant value even after an infinite period of time since the occurrence of
the last interference (sustained oscillation), the term self-excitation is used, and the
control loop is said to be unstable. This state must be avoided at all costs by correct
adjustment of the controller.
In unstable control loops two different types of oscillation can be distinguished –
periodically undamped oscillation and periodically excited oscillation:
• In the case of periodically undamped oscillation, the amplitude and frequency of
the sustained oscillation occurring after occurrence of the interference z are
constant (Fig. 4-3).
The control element must not travel to either the upper or lower limit position.
The time required for one full oscillation is referred to as the period of oscillation TP.
The loop gain that gives rise to undamped oscillation in the control loop is referred
to as the critical loop gain Vokrit. The proportional band Xp and the transfer coefficient
KR KP of the P-controller that produce this undamped oscillation are referred to as Xp
krit. and KR KP krit. respectively.
TPx
t
z
Fig. 4-3 Undamped oscillation
Tp Period of oscillation
z Interference
of the sustained oscillation that occurs (Fig. 4-4). It occurs if the
control loop is set higher than its critical value.
x
z
t
Fig. 4-4 Excited oscillation
z Interference
In practice, the amplitude of oscillation continues to increase as
limited by the end stops, e.g. valve fully open or valve closed.
In a stable control loop, oscillations of the controlled variable a
interference, but their amplitude decreases over time until they d
This is referred to as damped oscillation. A steady state, i.e. re
(Fig. 4-5).
z
x
t
Fig. 4-5 Damped oscillation
z Interference
A steady state, and therefore rest, occurs if the loop gain VO of t
Undamped oscillation Damped oscillation
73. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONTROL QUALITY
• Places of disturbance may vary
• Influence on measured output, system input or system output
• Control deviation should be minimized over time
• Especially relevant for real-time systems
73
Dirk Müller: Design of SW for embedded Sys., Winter term 2013/14
Relationship to RT (2/2)
t
r
Latency or
settling time
(e.g. until
deviation
below 3%)
y
e(t3): here overshoot
(as maximum)
t3
∫
t1
t2
∣r(t)−y(t)∣dt
t1 t2
● Error e and integral give inspiration for first (simple)
control path and controller types
=> P controller and I controller
74. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONTROLLER
• How to create a reasonable controller ?
• Desired value of controlled variable given by set point
• Compute new value of a control / actuating variable to
correct the error between measured variable and set point
• Often, controlled variable is physical, while measured variable is
the representation of it
• Create a control path
from basic elements
• Proportional (P) element
• Integral (I) element
• Derivative (D) element
74
[Wiikipedia]
75. PT 15/16
Design of Software for
Embedded Systems (SWES)
ELEMENTS
• Proportional (P) element
• Perform immediate proportional reaction to error at output
• Adjusted by gain factor kP
• Integral (I) element
• Accumulate past errors and react on them
• Adjusted by gain factor kI
• Derivative (D) element
• Based on current rate of change of the error, predict the future
• Adjusted by gain factor kD
75
76. PT 15/16
Design of Software for
Embedded Systems (SWES)
PROPORTIONAL ELEMENT
• Output is proportional
to the current error
• Gain factor too low:
Reaction not good
enough to fix the error
• Gain factor too high:
Reaction to error is too
extreme (stability)
• Only instantaneous
reaction, therefore
steady-state error
76
77. PT 15/16
Design of Software for
Embedded Systems (SWES)
P CONTROLLER
• Example: Mechanical water level
control systems
• Adjustable inflow with valve 1
• Variable outflow with valve 2
• Float sensor 3
• Gate valve as control element
• Controlled variable is water level x
• Output variable y is position of gate valve
• Keep water level constant, regardless of water drawing
• Desired water level (set point) defined by lever attachment height h
77
water outlet (depending on the position of gate valve 2) rep
system. The control task is to keep the water level in the ta
spite of varying load (drawing of water). The desired water
the attachment height h of the lever.
Fig. 3-5 Model of a P-controller
1 Gate valve in inlet
2 Gate valve in outlet
2 Float (sensor)
4,5 Float attachment points
V1 Inlet volume
V2 Outlet volume
a+b Lever
h Attachment height of the lever
w Reference variable
x Controlled variable (water level)
Xp Proportional band
V2
V1
h
4 5
a b
1
Yh
Xp
3
x
230 cm
200
170
w
2
B33-4
[Siemens]
78. PT 15/16
Design of Software for
Embedded Systems (SWES)
INTEGRAL ELEMENT
• Output is proportional to
past error behavior
• Delayed reaction to
accumulated errors
• Can fix steady-state error
resulting from
proportional reaction
• May produce output that
exceeds the target
(overshoot)
78
79. PT 15/16
Design of Software for
Embedded Systems (SWES)
I CONTROLLER
• Integral-action controller
• Output variable formed from sum of
consecutive input variables over time
• Example:Tank with inlet and outlet
• Flow rate at inlet as input variable
• Level at output as output variable
• With constant flow rate, level remains constant
• With increased incoming flow, output flow is the same
• With input greater than discharge rate, level will raise
• Proportional reaction no longer suitable
• Needs integral reaction
79
[Siemens]
3.3.2 The integral-ac
3.3.2.1 General Example
Integrate, in this context has th
with integral action, the output
variables over a period of time
This can be demonstrated with
Fig. 3-10 Container as level contro
The controlled system in the e
with an inlet and an outlet. The
variable is the level (not the flo
xa
xe
200 l/h
200 l/h
Integrate, in this context has the sense of combining or adding. In control loop ele
with integral action, the output variable is formed from the sum of consecutive inp
variables over a period of time.
This can be demonstrated with a simple example
Fig. 3-10 Container as level controller, Example of a control loop with integral action response
The controlled system in the example is used to control level, represented by a ta
with an inlet and an outlet. The input variable is the flow rate at the inlet, and the o
variable is the level (not the flow rate) at the output. If we assume that the flow rat
the inlet is equal to theat at the outlet, then the level will remain constant. To reco
step rsponse, we need mentally to increase the flow by a sudden large amount. F
example, the inlet valve could be opended manually, so that now, the flow rate at
inlet is 300l/h instead of 200l/h. The discharge rate will remain unchanged. The ou
variable, i.e. the level, will increase continuously until the tank overflows.
We can now no longer maintain that there is a given output variable for every inpu
variable, since in our example, for any input variable which is greater than the
discharge rate, the level will rise until it overflows. This type of response is defined
integral action. The contents of the tank are given by the sum of the liquid flowing
the tank minus the quantity discharged. Only the length of the time taken to fill the
will be affected by the input variable. In other words, it is not the output variable its
but the rate of change of the outut variable, which depends on the input variable.
expressed by the formula:
va = KI . xe
S0169
xe2
t
xa
xe
xe1
xa1
xa2
xa
xe
Überlauf
t
200 l/h
200 l/h
200 l/h
300 l/h
80. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONTROLLERS
• P controllers are load-dependent
• Controlled variable cannot be kept constant at all loads
• Output variable is proportional to the input variable
• Quick reaction
• Residual derivation: Steady-state deviation
• I controllers are load-independent
• Control action builds up slowly, therefore time-dependent
• Manipulated variable changes as long as deviation is given
80
81. PT 15/16
Design of Software for
Embedded Systems (SWES)
• Combine best of both worlds:
PI controller
• Remove steady-state error,
get medium speed of reaction
• Fast P controller + load-
independent I controller
• Can be implemented in
different ways
• Mechanical / hydraulic /
electrical / electronic
solution
PI CONTROLLER
81
Therefore, after a certain time (t0…t1), the ma
of the sum of the two variables:
( )( )tIxIKePK
I
y
P
yPIy Δ⋅⋅⋅=Δ+Δ=Δ
Fig. 3-16 Step response of the PI-controller
Δyp P-component
ΔyI I-component
ΔyPI P-component and I-component
e
t
t
y
PI
I
P ΔyPI
ΔyI
ΔyP
0
t0 t1 B33-14
Therefore, after a certain time (t0…t1), the m
of the sum of the two variables:
( )( )tIxIKePK
I
y
P
yPIy Δ⋅⋅⋅=Δ+Δ=Δ
Fig. 3-16 Step response of the PI-controller
Δyp P-component
ΔyI I-component
ΔyPI P-component and I-component
e
t
t
y
PI
I
P ΔyPI
ΔyI
ΔyP
0
t0 t1 B33-14
[Siemens]
82. PT 15/16
Design of Software for
Embedded Systems (SWES)
DERIVATIVE ELEMENT
• Compute derivative
(„slope of change“)
of the error
• Again adjusted by gain
factor
• Initially, the error changes
dramatically, so D-element
compensates directly
• Afterwards, influence
reduces and P+I parts are
‚taking over‘
82
83. PT14/15
Design of Software for
Embedded Systems (SWES)
PID CONTROLLER
• Initial charge by D
• Reduction almost to P level
• Rises again from I influence
83
[Siemens]
As already known, with a D-component, the magnitude of the manipulated variable
change is proportional to the rate of change of the controlled variable or control
difference.
e y
P
I
D
PID
y
a)
b)
Fig. 3-25 PID-controller
a) Model
b) Step response
P P-component
I I-component
D D-component
The step response of the PID-controller (Fig. 3-25b) co
superimposition of the P-component, I-component and
shows that an initial large change of the manipulated v
element. This means that interference will not give rise
The manipulated variable y is then reduced almost to th
where it rises again in a linear fashion under the influen
the I-component, the PID controller compensates for se
disturbances with no residual deviation and is faster tha
PID
D
I
Tn
y
t
b)
B33-22
1
XP
= KP
84. PT14/15
Design of Software for
Embedded Systems (SWES)
PID CONTROLLER
• Date back to 1890 governor design and ship steering
• Based on observation of human ship controller
• Compensates based on current error, past error and change rate
• Optimum behavior
• Disturbance rejection - Stay at a given setpoint
• Command tracking - Implement setpoint changes
• Rise time - How fast going close to the final value
• Settling time -
How fast settling into some range around the final value
84
85. PT 15/16
Design of Software for
Embedded Systems (SWES)
DIGITAL PID CONTROLLER
• Digital microcontrollers implement control function
• Easier realization of non-linear behavior and adaptive control
• Reconfiguration of software possible
• Time-discrete, quantized behavior
• A/D and D/A conversion requires sampling
• Danger of instability through phase shift
• Restricted data word length
• Accumulation of rounding errors
• Quantization errors
• Overflow in calculation with wrap-around
85
Institut für Robotik und Prozessinformatik Technische Universität Braunschweig- 37/64 -
Einführung in die diskrete Signalverarbeitung
A/D-Wandlung
D/A-Wandlung
Institut für Robotik und Prozessinformatik Technische Uni- 38/64 -
Abhängigkeit der Abtastperiode T
86. PT 15/16
Design of Software for
Embedded Systems (SWES)
ADJUSTINGTHE CONTROLLER
• Controller adjustment by determining gain factors / coefficients
• Heuristic method by Ziegler / Nichols for P / PI / PID controllers
• Only suitable for stable systems, focus on disturbance compensation
• I-gain and D-gain set to zero, increase P-gain until oscillation
• Table lookup for gain parameters, based on oscillation period
• Empirical method
• Response too slow:-> Increase influence of P component, reduce
influence of I component afterwards
• Response oscillates slowly towards goal signal -> Increase influence of
P component, reduce influence of D component afterwards
• Overshooting -> Reduce influence of P component, increase influence
of I component afterwards
86
87. Design of Software for Embedded Systems
WS15/16
Design of Software for Embedded Systems
Chair of Operating Systems
Jafar Akhundov
Mathematical Theory of Systems
and Control
Chapter 3
88. http://osg.informatik.tu-chemnitz.de
Purpose of this Extended Lecture
▶ Control system engineering is a complex task
▶ What (I hope) you will take away from this lecture:
▶ Necessary basics to:
• Be able to understand simple systems
• Read further literature (if necessary)
• Communicate with engineers
• Build better systems
▶ Motivation to use math and modelling more frequently
▶ Appreciate another view on systems
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
88
89. http://osg.informatik.tu-chemnitz.de
Contents
1.Control System Design Process
2.Math Background
1.Complex Variables
2.Differential Equations
3.Laplace Transform
3.Modeling in Frequency Domain
1.Transfer Functions
2.Use case: translational mechanical systems
3.Block Diagram Composition
4.Time Response Analysis
1.Poles and Zeros of Transfer Function
2.1st-order Systems
3.2nd-order Systems
5.System Stability Analysis
6.PID-control Tuning
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
89
90. http://osg.informatik.tu-chemnitz.de
1.1 Control System Definition (refreshment)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
90
Definition: A control system consists of subsystems and
processes (or plants) assembled for the
purpose of obtaining a desired output with
desired performance, given a specified input.
▶ Two major goals of performance:
▶ Transient response
▶ Steady-State Error
Source: [2]
92. http://osg.informatik.tu-chemnitz.de
1.2 Open-Loop vs. Closed-Loop (refreshment)
Open-Loop
▶ Stable
▶ No feedback
▶ Not precise
▶ Cannot compensate disturbances
▶ Simple
▶ Cheap
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
92
Closed-Loop
▶ Can become unstable
▶ Has a feedback loop
▶ Precise
▶ Compensates disturbances
▶ Complex
▶ Expensive
93. http://osg.informatik.tu-chemnitz.de
1.3 Objectives of Analysis and Design
▶ Three major goals:
▶ Producing the desired transient response
▶ Reducing steady-state error
▶ Achieving Stability
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
93
Definition: Control system is stable if its natural response a) eventually
approaches zero or b) oscillates. If the natural response of the
system grows without bound and becomes much greater than
forced response, the system is considered unstable.
▶ Other goals:
• Finances
• Robust design
Source: [2]
94. http://osg.informatik.tu-chemnitz.de
Control System Design Process: Overview
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
94
Determine
a physical
system and
specifications
from the
requirements.
Draw a
functional
block diagram.
Transform the
physical system
into
a schematic.
If multiple blocks,
reduce the block
diagram to a
single block or
closed-loop system.
Analyze, design,
and test to see
that requirements
and
specifications
are met.
Use the schematic
to obtain a
block diagram,
signal-flow diagram,
or state-space
representation.
Source: [2]
95. http://osg.informatik.tu-chemnitz.de
Control System Design Process: Stages
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
95
1.Transform requirements into a physical system
1.Determine physical dimensions, e.g. position, mass
2.Using the requirements, define specifications for the design, e.g. transient response,
steady-state accuracy
2.Functional block diagram
1.Translate qualitative description into functional subsystems
2.Define interconnections between subsystems
3.Create schematic
1.Make approximations of the system
2.Make assumptions about subsystems
3.Simplify, but not oversimplify
4.Instantiate the modules from functional block diagram
Controller
Engine
Air Intake
User Input
Velocity
of a car
Source: [2]
96. http://osg.informatik.tu-chemnitz.de
Control System Design Process: Stages (2)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
96
4.Develop a mathematical model (block diagram)
1.From schematic and physical laws (Kirchhoff, Newton's)
2.Many systems can be described by a linear ODE which relates input with the output
3.Assumptions and approximations may simplify this ODE
4.Often other representations are used instead:
1.For linear, time-invariant (LTI) systems, Laplace transform derives a transfer function
2.Alternatively, one can-use state-space representation (possible for non-LTI systems)
5.Reduce Block Diagram
1.Single block
2.Only system input and output present
an
dn
c(t)
dtn
+ an 1
dn 1
c(t)
dtn 1
+ a0c(t) = bm
dm
r(t)
dtm
+ bm 1
dm 1
r(t)
dtm 1
+ b0r(t)
Input Output
r(t) c(t)
System
Source: [2]
97. http://osg.informatik.tu-chemnitz.de
Control System Design Process: Stages (3)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
97
6.Analyze and Design
1.Mostly testing and verification
2.Redesign if necessary
3.Test signals commonly used:
Input Function Use
Impulse Transient response
Step
Transient response
Steady-state error
Ramp Steady-state error
Parabola Steady-state error
Sinusoid
Transient response
Steady-state error
(t)
u(t)
u(t)t
1
2
u(t)t2
sin !t
Source: [2]
98. http://osg.informatik.tu-chemnitz.de
2.1. Complex Numbers (refreshment)
▶ Complex numbers were introduced to solve equations like:
▶ A complex number written in rectangular form:
▶ j is called the imaginary unit.
▶ Alternatively,
▶ R is the magnitude and is the phase of
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
98
z = x + jy, j =
p
1
x2
= 1
x = R cos ✓
y = R sin ✓
Real
Imaginary
z⇤
= x jy
z = x + jy
✓
✓
R
Rz✓
Source: [1]
99. http://osg.informatik.tu-chemnitz.de
Complex Numbers Properties (refreshment)
▶ Complex numbers written in the Euler form:
▶ Addition/Subtraction is easier to do in the rectangular form:
▶ Multiplication/Division are more convenient in the Euler form:
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
99
z = R cos ✓ + jR sin ✓
= R(cos ✓ + j sin ✓)
= Rej✓
z1 ± z2 = (x1 ± x2) ± j(y1 ± y2)
z1z2 = (R1R2)ej(✓1+✓2)
z1
z2
= (
R1
R2
)ej(✓1 ✓2)
Source: [1]
100. http://osg.informatik.tu-chemnitz.de
2.2 Differential Equations (refreshment)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
100
Definition: Differential equation is any equation which
contains derivatives, either ordinary
derivatives or partial.
Definition: Solution to a differential equation on an
interval is any function
which satisfies the equation on this interval.
↵ < t < y(t)
Definition: Order of differential equation is the larges
derivative present in it.
Source: [3]
101. http://osg.informatik.tu-chemnitz.de
2.2 Differential Equations (refreshment)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
101
▶ Example (Newton's Second Law):
F = ma
F = m
d2
x
dt2
Definition: Linear differential equation is any differential
equation that can be written in the following
form:
an(t)y(n)
(t) + an 1(t)y(n 1)
(t) + ... + a1(t)y0
(t) + a0(t)y(t) = g(t)
Note: there are no products of the function and its derivatives and neither the the function
or its derivatives occur to any power other than the first power.
Source: [3]
102. http://osg.informatik.tu-chemnitz.de
2.2 Differential Equations (refreshment)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
102
Definition: Differential equation is time-invariant if it
does not depend explicitly on time.
▶ Many techniques for solving ODEs:
▶ Linear 1st order ODEs
▶ Separable ODEs
▶ Exact ODEs
▶ Bernoulli ODEs
...
N(y)
dy
dx
= M(x)
dy
dt
+ p(t)y = g(t)
M(x, y) + N(x, y)
dy
dx
= 0
y0
+ p(x)y = q(x)yn
Source: [3]
103. http://osg.informatik.tu-chemnitz.de
2.3 Laplace Transform
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
103
▶ Motivation:
▶ Differential equation relates input to output, yes
▶ But: All system parameters, input and output are mixed up in the equation
▶ Hence: it is not a satisfying representation from a system perspective
Note: the notation for the lower limit means that even if the function is
discontinuous at t=0, it is possible to start integration prior to discontinuity.
Definition: The Laplace transform is defined as
where is a complex variable. Condition for existence:s = + j!
L|f(t)| = F(s) =
Z 1
0
f(t)e st
dt
Z 1
0
f(t)e kt
dt < 1, k 2 R
104. http://osg.informatik.tu-chemnitz.de
2.3 Laplace Transform Simple Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
104
▶ Problem: Find the Laplace transform of
▶ Solution:
f(t) = Ae at
u(t)
F(s) =
Z 1
0
f(t)e st
dt
=
Z 1
0
Ae at
e st
dt
= A
Z 1
0
e (s+a)t
dt
=
A
s + a
e (s+a)t
1
t=0
=
A
s + a
This integral converges only if
(s + a) < 0
s + a > 0
Source: [2]
105. http://osg.informatik.tu-chemnitz.de
2.3 Laplace Transform table
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
105
Function Transform
(t)
u(t)
u(t)t
e at
u(t)
sin(!t)u(t)
cos(!t)u(t)
1
1
s
1
s2
1
s + a
!
s2 + !2
s
s2 + !2
tn n!
sn+1
...
106. http://osg.informatik.tu-chemnitz.de
2.3 Laplace Transform Theorems
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
106
Linearity Theorem
Frequency Shift
Theorem
Time Shift
Theorem
Scaling Theorem
Differentiation
Theorem
L|kf(t)| = kF(s)
L|e at
f(t)| = F(s + a)
L|f1(t) + f2(t)| = F1(s) + F2(s)
L|f(t T)| = e sT
F(s)
L|f(at)| =
1
a
F(
s
a
)
L|
df
dt
| = sF(s) f( 0)
L|
d2
f
dt2
| = s2
F(s) sf( 0) f0
( 0)
...
107. http://osg.informatik.tu-chemnitz.de
2.3 Laplace Transform Another Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
107
▶ Problem: Find the Laplace transform of
▶ Solution:
f(t) = 6e 5t
+ e3t
+ 5t3
9
F(s) = 6
1
s ( 5)
+
1
s 3
+ 5
3!
s3+1
9
1
s
=
6
s + 5
+
1
s 3
+
30
s4
9
s
Source: [3]
108. http://osg.informatik.tu-chemnitz.de
2.3 Laplace Transform Complex Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
108
▶ Problem: Find the Laplace transform of
▶ Solution:
f(t) = t2
sin(2t)
F(s) =
4s
(s2 + 4)2
F0
(s) =
12s2
16
(s2 + 4)3
H(s) =
12s2
16
(s2 + 4)3
L|tf(t)| = F0
(s) L|tsin(at)| =
2as
(s2 + a2)2
Using the fact that and
Source: [3]
109. http://osg.informatik.tu-chemnitz.de
2.3 Inverse Laplace Transform
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
109
Definition: The inverse Laplace transform is defined as
where is a complex variable, is real and u(t) is a
unit-step function.
s = + j!
L 1
|F(s)| =
1
2⇡j
Z +j1
j1
F(s)est
ds = f(t)u(t)
Example
Problem: Find inverse Laplace transform of F(s) =
1
(s + 3)2
Solution: We use frequency shift theorem and the transform of L|u(t)t| =
1
s2
L 1
|
1
(s + a)2
| = e at
u(t)tSo, and f(t) = e 3t
u(t)t
Source: [2]
110. http://osg.informatik.tu-chemnitz.de
2.3 Partial-Fraction Expansion
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
110
▶ Problem: how to find an ILT of a complex function?
▶ Solution: we can convert the function into a sum of simpler terms, for which we know
the ILT.
▶ This method is called partial fraction expansion
▶ Assume that , where the order of is lower than that of
▶ If this is not the case, divide polynomials until this condition is fulfilled
▶ Three cases are possible:
▶ Roots of the denominator are real and distinct
▶ Roots of the denominator are real and repeated
▶ Roots of the denominator are complex or imaginary (not considered here)
F(s) =
N(s)
D(s)
N(s) D(s)
D(s)
Source: [2]
111. http://osg.informatik.tu-chemnitz.de
2.3 Partial-Fraction Expansion (Case 1)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
111
▶ Roots of denominator are real and distinct
▶ It is possible to write the PFE as a sum of terms
▶ Constants, called residues, form numerators
▶ For example,
▶ To find , we multiply this equation by (s+1) which isolates
▶ Then we let s approach -1 which eliminates last term and we get
▶ Similarly solving this for the second residue, we get
▶ The resulting function can be transformed now:
F(S) =
2
(s + 1)(s + 2)
=
K1
s + 1
+
K2
s + 2
K1 K1
2
s + 2
= K1 +
(s + 1)K2
s + 2
K1 = 2
K2 = 2
f(t) = (2e t
2e 2t
)u(t)
Source: [2]
112. http://osg.informatik.tu-chemnitz.de
2.3 Partial-Fraction Expansion (Case 2)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
112
▶ Case 2: Roots of denominator are real and repeated
▶ To find the residues for the roots of multiplicity greater than unity:
▶ For all other residues, use the method of PFE for the case 1
F(s) =
N(s)
D(s)
=
N(s)
(s + p1)r(s + p2)...(s + pn)
K1
(s + p1)r
+
K2
(s + p1)r 1
+ ... +
Kr
s + p1
+
Kr+1
s + p2
+ ... +
Kn
s + pn
Ki =
1
(i 1)!
di 1
F(s)
dsi 1 s! p1
, i = 1, .., r
Source: [2]
113. http://osg.informatik.tu-chemnitz.de
2.3 Using Laplace Transform To Solve Linear ODE
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
113
▶ Problem: Solve this differential equation if all initial conditions are zero.
d2
y
dt2
+ 12
dy
dt
+ 32y = 32u(t)
s2
Y (s) + 12sY (s) + 32Y (s) =
32
s
Y (s) =
32
s(s2 + 12s + 32)
=
32
s(s + 4)(s + 8)
Y (s) =
32
s(s + 4)(s + 8)
=
K1
s
+
K2
s + 4
+
K3
s + 8
K1 =
32
(s + 4)(s + 8) s!0
= 1
K2 =
32
s(s + 8) s! 4
= 2
K3 =
32
s(s + 4) s! 8
= 1
Y (s) = (1 2e 4t
+ e 8t
)u(t)
▶ Solution:
▶ Using differentiation properties and Laplace transform of unit-step response, we get:
Y (s) =
1
s
2
s + 4
+
1
s + 8
Source: [2]
114. http://osg.informatik.tu-chemnitz.de
2.3 Using Laplace Transform To Solve Linear ODE
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
114
In general:
1. Having a linear ODE, take a Laplace transform of the ODE using Laplace transform rules
and initial conditions
2. Algebraically solve the resulting equation
3. Take the inverse Laplace transform using PFE
Source: [2]
115. http://osg.informatik.tu-chemnitz.de
3.1 Transfer Functions
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
115
▶ It is now possible for us to give a definition of a function that algebraically relates
output of the system to its input
▶ Take a general n-th order linear time-invariant ODE:
▶ Here, a, b are constants and c(t) and r(t) are output and input, respectively
▶ Assuming that all initial conditions are =0 and taking Laplace transform of both sides:
▶ The ratio
is called the transfer function. It is evaluated with zero initial conditions.The output
can be found by:
an
dn
c(t)
dtn
+ an 1
dn 1
c(t)
dtn 1
+ ... + a0c(t) = bm
dm
r(t)
dtm
+ bm 1
dm 1
r(t)
dtm 1
+ ... + b0r(t)
(ansn
+ an 1sn 1
+ ... + a0)C(s) = (bmsm
+ bm 1sm 1
+ ... + b0)R(s)
C(s)
R(s)
= G(s) =
(bmsm
+ bm 1sm 1
+ ... + b0)
ansn + an 1sn 1 + ... + a0
C(s) = G(s)R(s)
Source: [2]
116. http://osg.informatik.tu-chemnitz.de
3.1 Transfer Functions - Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
116
▶ Problem: Find the transfer function represented by ODE:
▶ Solution:
▶ Taking Laplace transform of both sides and assuming zero initial conditions,
▶ If a system response is needed for a unit-step input:
▶ Using PFE and taking inverse Laplace transform:
dc(t)
dt
+ 2c(t) = r(t)
sC(s) + 2C(s) = R(s)
G(s) =
1
s + 2
C(s) = R(s)G(s) =
1
s(s + 2)
C(s) =
1/2
s
1/2
s + 2
c(t) =
1
2
1
2
e 2t
Source: [2]
117. http://osg.informatik.tu-chemnitz.de
3.2 Mechanical Translational Transfer Functions
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
117
Component Force-Displacement Transfer Function
Viscous damper
f(t), x(t)
b
f(t) = b
dx(t)
dt
bs
M
Mass
f(t), x(t) f(t) = M
d2
x(t)
dt2
Ms2
f(t), x(t)
K
Spring
f(t) = Kx(t) K
Source: [2]
118. http://osg.informatik.tu-chemnitz.deWS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
118
M
f(t), x(t)
Problem: Derive a transfer function
for this system
Solution: First, write down the differential equation describing the system
M
d2
x(t)
dt2
+ b
dx(t)
dt
+ Kx(t) = f(t)
Taking the Laplace Transform:
Ms2
X(s) + bsX(s) + KX(s) = F(s)
After some algebraic manipulations:
(Ms2
+ bs + K)X(s) = F(s)
1
Ms2 + bs + K
X(s)F(s)
3.2 Mechanical Translational Transfer Functions Example
X(s)
F(s)
=
1
Ms2 + bs + K
Source: [2]
119. http://osg.informatik.tu-chemnitz.de
Summary of the last lecture
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
▶ Previous lecture was about step 4 of control design: creating a mathematical model
▶ How do we do that?
• Describe a system as a differential equation
• If the differential equation is ordinary, time-invariant and linear, we use Laplace
transform
• As a result, we get representation of the system in complex domain (transfer function)
▶ Why do we do that?
• Easy solution of differential equations
• Easy reduction of complex systems (step 5): discussed in this lecture
• Easy reasoning about time response, stability (step 6): discussed in this lecture
119
120. http://osg.informatik.tu-chemnitz.de
3.3 Block diagrams
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
▶ Complex systems are represented by interconnections of many subsystems
▶ Our goal: represent response of the whole system as a single transfer function
▶ Block diagrams are used for frequency-domain analysis and design
▶ Signal flow graphs are used for state-space methods
▶ Subsystem is represented as a block with: input, output and transfer function
Input Output
R(s) C(s)
G(s)
System
+
+
R1(s)
R2(s)
R3(s)
C(s) = R1(s) + R2(s) R3(s)
Summing junction Pickoff point
R(s)
R(s)
R(s)
R(s)
▶ For building more complex systems, two more elements are needed:
Source: [2]
120
121. http://osg.informatik.tu-chemnitz.de
3.3 Cascade Form of Transfer Functions
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
121
R(s) C(s)
G3(s)G2(s)G1(s)
Source: [2]
R(s)
G1(s) G2(s) G3(s)
G1(s)R(s) G2(s)G1(s)R(s) G3(s)G2(s)G1(s)R(s)
C(s) =
122. http://osg.informatik.tu-chemnitz.de
3.3 Parallel Form of Transfer Functions
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
122
R(s)
G1(s)R(S)
G1(s)
G2(s)
G3(s)
±
±
±
G2(s)R(s)
G3(s)R(s)
C(s) = (±G1(s) ± G2(s) ± G3(s))R(s)
R(s) C(s)
±G1(s) ± G2(s) ± G3(s)
Source: [2]
123. http://osg.informatik.tu-chemnitz.de
3.3 Feedback Form of Transfer Functions
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
123
R(s) +
⌥
C(s)E(s)
G(s)
H(s)
error
Plant and
Controller
Input Output
Feedback
R(s) C(s)
G(s)H(s) is called loop gain or open loop transfer function
G(S)
1 ± G(s)H(s)
E(s) = R(s) ⌥ C(s)H(s)
Using
C(s) = E(s)G(s) ) E(s) =
C(s)
G(s)
and
G(S)
1 ± G(s)H(s)
we get:
and solving for
C(s)
R(s)
= Ge(s)
Source: [2]
124. http://osg.informatik.tu-chemnitz.de
3.3 Restructuring Topologies (Summing Junction)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
124
R(s) +
⌥
G(s) ⌘
X(s)
R(s) +
⌥
G(s)
X(s)
G(s)
C(s) C(s)
Source: [2]
R(s) +
⌥
G(s) ⌘
X(s)
R(s) +
⌥
X(s)
G(s)
C(s) C(s)
1
G(s)
125. http://osg.informatik.tu-chemnitz.de
3.3 Restructuring Topologies (Summing Junction)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
125
R(s)
⌘
G(s)
1
G(s)
R(s)
R(s)
R(s)G(s)
R(s)
R(s)
R(s)
R(s)G(s)
G(s)
1
G(s)
R(s)
G(s)
R(s)G(s)
R(s)G(s)
R(s)G(s)
⌘
R(s)
R(s)G(s)
G(s)
G(s)
G(s)
R(s)G(s)
R(s)G(s)
Source: [2]
126. http://osg.informatik.tu-chemnitz.de
3.3 Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
126
▶ Problem: reduce the block diagram and find the transfer function of the system:
Source: [2]
R(s) + C(s)
G1(s) G2(s)
H2(s)
H1(s)
H3(s)
G3(s)
+
+ +
127. http://osg.informatik.tu-chemnitz.de
3.3 Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
127
▶ Step 1: collapse 3 summing junctions into a single one
R(s) + C(s)
G1(s) G2(s)
H2(s)
H1(s)
H3(s)
G3(s)
+
Source: [2]
128. http://osg.informatik.tu-chemnitz.de
3.3 Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
128
▶ Steps 2&3: use cascade, parallel and feedback forms to get the final result
R(s) C(s)G3(s)G2(s)G1(s)
1 + G3(s)G2(s)(H1(s) H2(s) + H3(s))
+ C(s)
G3(s)G2(s)
H1(s) H2(s) + H3(s)
R(s)
G1(s)
Source: [2]
129. http://osg.informatik.tu-chemnitz.de
4. Time Response
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
129
▶ The output of the system is the sum of two responses
▶ Forced Response
▶ Natural Response
▶ Problem: We want to be able to rapidly evaluate output response without solving DE or
taking inverse Laplace transform
▶ Solution: Using poles and zeros of the transfer function
Source: [2]
▶ We can now turn to analysis of the system
▶ Last stage of the control system design process
▶ Here only
▶ Time Response
▶ Stability Analysis
130. http://osg.informatik.tu-chemnitz.de
4.1 Poles and Zeros
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
130
Source: [2]
Definition: The poles of a transfer function are
(1) the values of the complex Laplace transform variable s that make the
transfer function infinite
(2) roots of denominator that are also roots of the numerator
N(s)
D(s)
Definition: The zeros of a transfer function are
(1) the values of the complex Laplace transform variable s that cause the
transfer function to become zero
(2) roots of numerator that are also roots of the denominator
N(s)
D(s)
131. http://osg.informatik.tu-chemnitz.de
4.1 Poles and Zeros Example
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
131
Source: [2]
G(s)
C(s)
R(s) =
1
s s + 2
s + 5
j!
s-plane
25
A =
s + 2
s + 5 s!0
=
2
5
B =
s + 2
s s! 5
=
3
5
c(t) =
2
5
+
3
5
e 5t
Forced response Natural response
Pole of the input function generates forced response
Pole of the transfer function generates natural response
Zeros and poles generate amplitudes for both natural and forced responses.
C(s) = G(s)R(s) =
s + 2
s(s + 5)
=
A
s
+
B
s + 5
132. http://osg.informatik.tu-chemnitz.de
4.2 First-Order Systems
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
132
Source: [2]
G(s)
C(s)b
s + a
R(s)
j!
s-plane
a
C(s) = R(s)G(s) =
a
s(s + a)
C(s) =
K1
s
+
K2
s + a
K1 =
b
a
K2 =
b
a
↵ =
b
a
c(t) = ↵(1 e at
)
C(S) = ↵(
1
s
1
s + a
))
c(t) = 1 e at
|t=1/a = 1 e 1
= 0.63
b = a ) ↵ = 1For simplicity:
133. http://osg.informatik.tu-chemnitz.de
4.2 First-Order Systems Characteristics
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
133
Source: [2]
Definition: is called time constant, time needed for the step response to reach
63% of its final value
1
a
Definition: Rise time is defined as the time for the response to go from 0.1 to 0.9 of
its final value:
Tr =
2.2
a
Definition: Settling time is defined as the time for the response to reach and stay
within 2% of its final value:
Ts =
4
a
135. http://osg.informatik.tu-chemnitz.de
4.3 Second-Order Systems
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
135
Source: [2]
▶ 1st-order systems are easy to analyse and handle:
▶ single parameter
▶ the a-parameter is responsible for the speed of response
▶ 2nd-order systems parameters change the form of the response as well
▶ General form:
G(s)
C(s)
R(s) =
1
s b
s2 + as + b
136. http://osg.informatik.tu-chemnitz.de
4.3 Second-Order Systems Types (1)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
136
Source: [2]
G(s)
C(s)
R(s) =
1
s 9
s2 + 9s + 9
G(s)
C(s)R(s) =
1
s 9
s2 + 2s + 9
j!
s-plane
7.9 1.1
j!
s-plane
1 + j
p
8
1 j
p
8
Overdamped
Underdamped
137. http://osg.informatik.tu-chemnitz.de
4.3 Second-Order Systems Types (2)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
137
Source: [2]
G(s)
C(s)R(s) =
1
s 9
s2 + 9
G(s)
C(s)R(s) =
1
s 9
s2 + 6s + 9
j!
s-plane
j3
j3
j!
s-plane
3
Undamped
Critically Damped
138. http://osg.informatik.tu-chemnitz.de
4.3 Second-Order Systems Types (3)
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
138
Source: [2]
Type of Response Poles Response
Overdamped Two real at
Underdamped Two complex at
Undamped Two imaginary at
Critically Damped Two real at
1, 2
1
d ± j!d
±j!1
c(t) = K1e 1t
+ K2e 2t
c(t) = Ae dt
cos(!dt )
c(t) = A cos(!1t )
c(t) = K1e 1t
+ K2te 1t
139. http://osg.informatik.tu-chemnitz.de
4.3 General Second-Order System
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
139
Source: [2]
▶ It is possible to describe a 1st-order system behaviour with time constant a
▶ We want to do the same for 2nd-order systems:
▶ This time two parameters are needed
▶ Natural frequency = frequency without damping
▶ Damping ratio which quantitatively describes damped oscillation regardless of
time scale
!n
⇠
G(s) =
b
s2 + as + b
G(s) =
b
s2 + b
⇠ =
Exponential decay frequency
Natural frequency
=
a/2
!n
Rewriting in general form:
G(s) =
!2
n
s2 + 2⇠!s + !2
n
!n =
p
b
140. http://osg.informatik.tu-chemnitz.de
4.3 General Second-Order System
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
140
Source: [2]
Response
Type
Undamped
Underdamped
Critically
Damped
Overdamped
⇠
⇠ = 0
0 < ⇠ < 1
⇠ = 1
⇠ > 1
141. http://osg.informatik.tu-chemnitz.de
4.3 Second-Order System Characteristics
Semester 141
Definition: Peak time is the time required to for the response waveform to reach the
first, or maximum, peak.
Definition: Rise time is defined as the time for the response to go from 0.1 to 0.9 of
its final value.
Definition: Settling time is defined as the time for the response to reach and stay
within 2% of its final value.
Source: [2]
Definition: Percent overshoot is the amount the response waveform overshoots the
steady-state, expressed as a percentage of steady-state value.
142. http://osg.informatik.tu-chemnitz.de
5. System Stability Analysis
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
142
Source: [2]
▶ Stability is the one of the most important properties of the system
▶ If a system is unstable, transient response and steady-state errors are meaningless
Definition(BIBO): A system is stable if every bounded input produces a bounded output.
Alternatively, a system is unstable if any bounded input produces an unbounded output.
Definition: Control system is stable if its natural response a) eventually
approaches zero or b) oscillates. If the natural response of the
system grows without bound and becomes much greater than
forced response, the system is considered unstable.
143. http://osg.informatik.tu-chemnitz.de
5. System Stability Analysis
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
143
Source: [2]
▶ How to check if the system is stable? Many possibilities
▶ Informally, by inspecting closely the transfer function
▶ Formally, e.g. Routh-Hurwitz Analysis
▶ Informal analysis:
▶ Recall:
Observation 1:
• Poles in the left-half complex plane produce either exponential decay or
damped sinusoidal response
• Thus, stable systems have closed-loop transfer functions with poles exclusively
in the lhp.
144. http://osg.informatik.tu-chemnitz.de
5. System Stability Analysis
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
144
Source: [2]
Observation 2:
• Poles in the right half-plane yield
• pure exponentially increasing responses
• exponentially increasing sinusoidal responses
• Thus, unstable systems have closed-loop transfer functions with at least one pole
in the rhp and/or poles of multiplicity greater than 1 on the imaginary axis
Observation 3:
• Poles which are purely imaginary with multiplicity exactly 1 produce pure
oscillations (sinusoidal) which neither increasing nor decreasing amplitude
• Thus, marginally stable systems have closed-loop transfer functions with purely
imaginary poles of multiplicity 1 and poles in the lhp
145. http://osg.informatik.tu-chemnitz.de
5. Informal System Stability Analysis: Example 1
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
145
Source: [2]
+ C(s)E(s)
R(s) =
1
s 3
s(s + 1)(s + 2)
j!
s-plane
0.16 + j1.04
0.16 j1.04
2.67
Careful: THIS is NOT the transfer function of the system!
Apply the feedback rule to find TF and solve!
146. http://osg.informatik.tu-chemnitz.de
5. Informal System Stability Analysis: Example 2
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
146
Source: [2]
j!
s-plane
0.04 + j1.5
0.04 j1.5
3.087
+ C(s)E(s)
R(s) =
1
s 7
s(s + 1)(s + 2)
Careful: THIS is NOT the transfer function of the system!
Apply the feedback rule to find TF and solve!
147. http://osg.informatik.tu-chemnitz.de
5. Informal System Stability Analysis: Problem
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
147
Source: [2]
▶ A problem arises when a transfer function is given in an unfactored way
10(s + 2)
s5 + 28s4 + 284s3 + 1232s2 + 1930s + 20
=
10(s + 2)
s(s + 4)(s + 6)(s + 8)(s + 10)
▶ In such a case it is possible to use calculator or computer to find the roots
▶ Or use other techniques to analyse for stability, e.g. Routh-Hurwitz method
148. http://osg.informatik.tu-chemnitz.de
6. PID-Tuning
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
148
▶ How to determine optimal values for PID-controller?
▶ Depends on definition of optimality
▶ Possible goals:
• Stability
• Minimum overshoot
• Damped noise
• Minimum steady-state error
• Short settling time
149. http://osg.informatik.tu-chemnitz.de
6. Ziegler-Nichols Method for PID-Tuning
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
149
▶ Several possible methods exist
▶ One of the simplest: Ziegler-Nichols Method
▶ First, the ultimate gain parameter has to be found
▶ Ultimate gain factor describes the value of the P-controller which makes the
system oscillate with undamped constant amplitude indefinitely with period
Ku
Tu
Control Type
PI -
Classic PID
No Overshoot
PID
Ti TdKp
0.45Ku Tu/1.2
0.6Ku
0.2Ku
Tu/2
Tu/2
Tu/8
Tu/3
150. http://osg.informatik.tu-chemnitz.de
References
WS15/16
Design of Software for Embedded Systems
Chapter 3: Mathematical Theory of Systems and Control
150
▶ [1] Benjamin C. Kuo and Farid Golnaraghi. 2002. Automatic Control Systems (8th
ed.). John Wiley & Sons, Inc., New York, NY, USA.
▶ [2] Norman S. Nise. 2011. Control Systems Engineering (6th ed.). John Wiley & Sons,
Inc., New York, NY, USA.
▶ [3] Paul Dawkins. Paul's Online Math Notes - Differential Equations, 2007,
http://tutorial.math.lamar.edu/Classes/DE/DE.aspx
▶ [4] Joseph J. Distefano, Allen J. Stubberud, and I. J. Williams. 1997. Schaum's
Outline of Feedback and Control Systems (2nd ed.). McGraw-Hill Professional.
151. C
DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES)
Dr. PeterTröger
Operating Systems Group,TU Chemnitz
152. PT 15/16
Design of Software for
Embedded Systems (SWES)
C
• C belongs to the most popular programming languages
• Developed in the early 70s by Dennis Ritchie at Bell Labs
• Imperative, structural, very small number of basic keywords
• Portable and efficient => used for embedded systems
• All major operating systems are written (mostly) in C
• Thin layer above assembler language
• Data type semantics driven by hardware architecture
• Direct memory manipulation, inline assembler supported
• Few chances for compiler to check semantic correctness
• Standards: C89/C90, C95, C99, C11
152
153. PT 15/16
Design of Software for
Embedded Systems (SWES)
HELLO WORLD
• Implementation / source files (*.c)
• Declaration / header files (*.h)
• Object files (*.o on Unix, *.obj on Windows)
• Static library files (*.a on Unix, *.lib on Windows)
• Dynamic library files (*.so on Unix, *.dll on Windows)
• Entry point is always the main() function, result available in the OS
153
#include <stdio.h>
int main(void)
{
printf("Hello, Worldn");
return 0;
}
154. PT 15/16
Design of Software for
Embedded Systems (SWES)
TECHNICAL ENVIRONMENT
154
Code /
Model
Compiler
Object file for target
Remote debugger
Terminal
HW debugging support
SW outputs
Developer PC Embedded system
JTAG
Serial
Executed code
Transfer
155. PT 15/16
Design of Software for
Embedded Systems (SWES)
C PREPROCESSOR
• C preprocessor
• Simple text replacement
for „#define“
and „#include“
• C Header Files
• Separate declaration
and implementation
• „#include“ preprocessor directive includes one file in another file
• Easiest way to include declaration into implementation file
• Embedded world: Nice to separate hardware specifics
• Several predefined macros: __LINE__, __FILE__, __TIME__, ...
155
# if SYSTEM == SYSV
# define HDR ”sysv.h”
# elif SYSTEM == BSD
# define HDR ”bsd.h”
# else
# define HDR ”default.h”
# endif
# include HDR
157. PT 15/16
Design of Software for
Embedded Systems (SWES)
C STATEMENTS
• Statement syntax has influenced C++, Java, C# and many others
• if(condition) statement else statement
• for(init;condition;step) statement
• while(condition) statement
• do statement while(condition);
• switch(condition) { case-block }
• Blocks
• Expressions
• return, break, continue
157
158. PT 15/16
Design of Software for
Embedded Systems (SWES)
C DATATYPES
• Only a few scalar basic types in C
• char - Smallest addressable unit of the machine, at least 8 bit,
contains character in local character set, may be signed or unsigned
• int - Integer, supposed to be most efficient on the hardware
• Qualifiers: long (at least 32 bit), short (at least 16 bit)
• sizeof(char) <=sizeof(short) <= sizeof(int) <= sizeof(long)
• float - Floating point number with single precision
• double - Floating point number with double precision
• Support for enumerations
• signed, unsigned -Type qualifiers
158
160. PT 15/16
Design of Software for
Embedded Systems (SWES)
64 BIT DATA MODELS
160
[Wikipedia]
161. PT 15/16
Design of Software for
Embedded Systems (SWES)
C DATATYPES
• Several data representations depend on the underlying hardware
• Ideal for hardware-oriented performance tuning
• Use data type sizes close to register width / processor capabilities
• Especially relevant with very small hardware (e.g. micro controllers)
• Well-known issues with code correctness
• Tradeoff: Potential performance vs. bug probability
• Floating points in accordance to IEEE 754
• char variables are technically just 8-bit integers
• Value is position in the character set, e.g.ASCII, EBCDIC, UTF-8
• No native string type, but support for character arrays
161
162. PT 15/16
Design of Software for
Embedded Systems (SWES)
MEMORY IN C
• Operating system provides virtual memory address space for process
• Static variables, stored in separate region (bss)
• Local variables, allocated on the stack
• Each function call stores information on the stack
• Return address, return values, parameters, local variables
• Dynamically allocated memory regions in the heap (e.g. malloc)
• Shared memory regions
• volatile keyword for variables
• Tells the compiler that the value may change outside the normal
control flow of the program (e.g. by hardware)
162
163. PT 15/16
Design of Software for
Embedded Systems (SWES)
MEMORY IN C
• Function to wait for register change
• Some interrupt routine will concurrently modify the value of reg
• Code compiled with activated optimizations
• Visible effect
• Function may never return, although register changes
• What is wrong ? (typical problem in embedded C coding)
163
void IOWaitForRegChange(unsigned int* reg, unsigned int bitmask){
unsigned int orig = *reg & bitmask;
while (orig == (*reg & bitmask)) {;}
}
164. PT 15/16
Design of Software for
Embedded Systems (SWES)
C POINTERS
• Pointer:Variable that contains some memory address
• Some location:Another variable, allocated heap memory, function
implementation, operating system data structure, shared memory, ...
• Excessively used as concept in C
• Maps directly to addressing in
assembler language
• Pointer variable is typed with
respect to the data it points to
• & operator for adress
determination
• * operator for de-referencing
164
int x = 1, y = 2, z[10];
int *ip;
ip = &x;
y = *ip; *ip = 0;
ip = &z[0];
165. PT 15/16
Design of Software for
Embedded Systems (SWES)
C POINTERS
• C only knows call-by-value
• Implement call-by-reference by
providing a pointer
• Pointer value is copied
165
int x = 1, y = 2, z[10];
int *ip;
ip = &x;
y = *ip; *ip = 0;
ip = &z[0]; swap( &a, &b );
----------------------------
void swap( int *px, int *py)
{
int temp = *px;
*px = *py;
*py = temp;
}
166. PT 15/16
Design of Software for
Embedded Systems (SWES)
ARRAYS AND POINTERS
• Value of an array variable is the address
of the first element
• Every array indexing operation can be
expressed as pointer operation
• Sometimes faster
• Array and pointer are not the same
• Arrays are not variables, not allowed
on left side of an expression
• Arrays as function argument result in
address of the first element
• Allows to hand over only parts of
the array to some function
166
*(array_var+3)
pa = &a[0];
equals
pa = a;
a[i]
equals
*(a+i);
func(&a[2]);
167. PT 15/16
Design of Software for
Embedded Systems (SWES)
ARRAYS AND POINTERS
167
void strcpy1( char * s, char * t ) {
int i = 0;
while ((s[i] = t[i]) != ‚0')
i++;
}
void strcpy2( char * s, char * t ) {
while ((*s = *t) != '0')
{ s++; t++; }
}
168. PT 15/16
Design of Software for
Embedded Systems (SWES)
ARRAYS AND POINTERS
• Pointers can be added, subtracted and compared
• Pointer arithmetics - very efficient and dangerous tool
• Inc / dec steps in accordance to the data type being pointed to
• All pointers can be converted to „void*“ and reverse
• No runtime checks for memory access through array index or pointer
• Compiler converts it to native code, no underlying runtime
• Illegal access may be defeated by operating system
• Unintended access to process data possible
(stack-based buffer overflow attack on return address)
• Pointer can reference functions (start address in code segment)
168
(* compare) ( ”hello”, ”world” );
169. PT 15/16
Design of Software for
Embedded Systems (SWES)
BUFFER OVERFLOW
169
Local variables of main()
Free
Code,
main() calling foo()
Code,
foo() running
Local variables of main()
Return address
Local variables of foo()
Free
Code,
foo() running
Local variables of main()
Return address
Local variables of foo()
Free
SP
SP
Overflow
0x0000...
170. PT 15/16
Design of Software for
Embedded Systems (SWES)
DEALING WITH STRINGS
• pmessage: Pointer can be changed, but not the text
• amessage:Text can be changed
• [] and * can both be used on arrays
• Pointer arithmetic may save a fixed-size index variable
170
171. PT 15/16
Design of Software for
Embedded Systems (SWES)
APPLICATION PROGRAMMING INTERFACE
171
C
Application
C Library API
Hardware
„Bare Metal“
C Library API
Operating
Systems acting
as Hosted C
Environment
System Calls
Hardware
UNIX OS API
Unix
Operating
System Flavor
(BSD / SYSV)
System Calls
Hardware
Windows API
Windows
Operating
Systems
System Calls
Hardware
POSIX API
Unix
(and Windows)
Operating
Systems
System Calls
Hardware
Other libraries
172. PT 15/16
Design of Software for
Embedded Systems (SWES)
DEPENDABLE C CODE
• Low-level approach makes C code fast and memory-efficient
• But also only minimal protection from programmer mistakes
• Different ways to achieve dependable C code
• Fault avoidance - Prevent bugs from being introduced
• Coding conventions or C code generation
• Depends on understanding of typical fault causes
• Fault removal - Find bugs before going
into production
• Testing, whole program analysis
• Fault tolerance and fault prediction
172
173. PT 15/16
Design of Software for
Embedded Systems (SWES)
DEPENDABLE C CODE
• Problematic properties of the C language
• Intentionally implementation-defined behavior
• Examples:
Expression evaluation order, numerical types, register type
• Chance for compiler optimizations
• Intentionally non-portable semantics
• Example: LOCALE in character / string handling
• Intentionally undefined behavior
• Example: Reaction on run-time problems,
such as non-initialized variables being used
173
174. PT 15/16
Design of Software for
Embedded Systems (SWES)
STYLE ISSUES
174
if (a==b) c=0;
if (a==b); c=0;
a & b
a && b
a = b
a == b
for (i=0; i<sizeof(s)‐1&&(c=getchar())!=’n’ && c!=EOF; i++)
s[i] = c;
s[i+1] = 0;
int i;
float f, g;
g = f + i;
i = f + g;
Code Structuring
Expressions
Type conversion
Operators
Readability
int i=1;
{
int i=2;
}
Names & Scopes
175. PT 15/16
Design of Software for
Embedded Systems (SWES)
STYLE ISSUES
175
char **argv // Pointer to char array
int (*daytab)[13] // Pointer to int array
int *daytab [13] // Array of int pointers
void *comp () // Function returning void pointer
void (*comp)() // Pointer to function returning void
// Function returning pointer to an array, which contains
pointers to functions returning char
char (*(*x() ) [] )()
// Array of pointers to functions,
// which return a pointer to an array
char (* (*x[3])() )[5]
176. PT 15/16
Design of Software for
Embedded Systems (SWES)
IOCCC.ORG
176
http://ioccc.org/years-spoiler.html
177. PT 15/16
Design of Software for
Embedded Systems (SWES)
C STYLE GUIDES
177
178. PT 15/16
Design of Software for
Embedded Systems (SWES)
RULES
• No dependence should be placed on C’s operator precedence
• Only compound statements after
if, else, while, for, switch, case, do
• Naming conventions for variables
• Constants in UPPER CASE
• Type names start with upper case letter, e.g. struct Ports
• ...
178
x=(a*b)+c; x=a*b+c;
while (i > 0)
*t++ = *s++;
while (i > 0){
*t++ = *s++;
}
179. PT 15/16
Design of Software for
Embedded Systems (SWES)
FUNCTION MACROS
• Code considers
platform specifics on
memory copy
operation
• memcpy()
function may be
implemented by a
preprocessor macro
• Compiler behavior
undefined
• Either re-formulate
code or forbid
function macros
179
[https://www.securecoding.cert.org/]
180. PT 15/16
Design of Software for
Embedded Systems (SWES)
FUNCTION MACROS
• Side effects in
arguments to
function macros may
raise problems
• Different solutions
• Perform ++n
before function call
• Replace function
macro with
inline function
180
[https://www.securecoding.cert.org/]
181. PT 15/16
Design of Software for
Embedded Systems (SWES)
TYPE CONVERSIONS
• Handle down-cast of
values explicitly
181
[https://www.securecoding.cert.org/]
182. PT 15/16
Design of Software for
Embedded Systems (SWES)
POINTERS
• getenv documentation
declares that returned
pointer should not be
stored
• Code may lead to
overwriting of first result
• Variables are considered
the same even though
they are not
• ‚Heisenbug‘
182
[https://www.securecoding.cert.org/]
183. PT 15/16
Design of Software for
Embedded Systems (SWES)
COMMENTING
• Code implements an algorithm
• High-level comments for major software modules
• Fine granularity comments explaining non-obvious details
• Header files should have comment block
• Only readable part of library code
• Version information, usage license, authors, support contact
183
/*******************************************************************
* Product: . .
* Version: . .
* Updated: November 26 2015
* Copyright (C) 2015-2015 Brillant student <brilliant@student.org>
* <licensing terms> (if any)
*******************************************************************/
184. PT 15/16
Design of Software for
Embedded Systems (SWES)
COMMENTING
184
[freescale.com]
185. PT 15/16
Design of Software for
Embedded Systems (SWES)
DATATYPES
• Typical example for
memory-mapped I/O
• Compiler determines
offsets for individual
registers
• Allows struct-
based access
• struct definition
may not be portable
• Semantical, not
syntactical issue
185
// Define struct overlay
typedef struct
{
unsigned int count; // Offset 0x00
unsigned int max; // Offset 0x02
unsigned int _reserved; // Offset 0x04
unsigned int flags; // Offset 0x06
} Counter;
// Create pointer to chip base address
Counter volatile * const pCounter = 0x10000000;
// Next line is equal to
// *((unsigned int *)0x10000002) = 5000;
pCounter->max = 5000;
pCounter->flags |= GO;
...
// Poll timer state
if (pCounter->flags &= DONE)
{ ... }
186. PT 15/16
Design of Software for
Embedded Systems (SWES)
DATATYPES
• Same single-line instruction on different processors
• Choice of data type impacts assembler code efficiency
• Trade-off between optimal portability and optimal performance
186
[freescale.com]
187. PT 15/16
Design of Software for
Embedded Systems (SWES)
DATATYPES
• Raw C data types allows compiler to choose most efficient storage
• Most coding conventions recommend to not use them
• Projects define their own data type abstractions
• <stdint.h> for C99 provides portable data types
• int8_t: signed 8-bit uint8_t: unsigned 8-bit
• int16_t: signed 16-bit uint16_t: unsigned 16-bit
• int32_t: signed 32-bit uint32_t: unsigned 32-bit
• int64_t: signed 64-bit uint64_t: unsigned 64-bit
187
for (int i=0; i < N; i++) { ... }
188. PT 15/16
Design of Software for
Embedded Systems (SWES)
DATATYPES
188
// int j;
SI_32 j;
for (j = 0; j < 64; j++) {
if (arr[j] > j*1024){
arr[j]=0;
}}
#include <limits.h>
#if (INT_MAX == 0x7fffffff)
typedef int SI_32;
typedef unsigned int UI_32;
#elif (LONG_MAX == 0x7fffffff)
typedef long SI_32;
typedef unsigned long UI_32;
#else
#warning "No 32 bit type."
#endif
189. PT 15/16
Design of Software for
Embedded Systems (SWES)
CONST CORRECTNESS
• const keyword in C for read-only variable
• Allows compiler to put value into ROM
• Does not happen when #define is
used instead
• In contrast to other languages, it is a
property of the type
• Part of compile-time type checking, which
is good
• Most other languages allow to define
constant objects instead
189
const int x=1;
void f(int& x);
// ...
const int i;
f(i);
int const *px;
int * const px;
190. PT 15/16
Design of Software for
Embedded Systems (SWES)
MISRA-C
• MISRA: Motor Industry Software Reliability Association
• MISRA-C: Programming standard from automotive industry
• Restriction on C programming language („language sub-set“)
• Goal is to make code as predictable as possible for disperse teams
• Set of rules for C programs (mandatory, required, advisory)
• Strict process for dealing with ignored non-mandatory rules
• Rules either enforced with code generation or static checking
• First version created in 1998, related to C89 standard
• Third version MISRA-C:2012, related to C99 standard
• Since 2008 also MISRA-C++ available
190
191. PT 15/16
Design of Software for
Embedded Systems (SWES)
MISRA-C RULES
• Categories of problems being tackled
• Common programming errors in C
• Underspecified language aspects, interpreted by compiler vendors
• Common misconceptions of C language properties
• Compiler errors and runtime errors
• Targeting human developers
• Some problems never occur in code generators
• Rule may even impact performance (http://bit.ly/1pGpHpo)
• In MISRA-C 2012, 27 undecidable rules
• No possible to evaluate rule in each and every case
191
192. PT 15/16
Design of Software for
Embedded Systems (SWES)
MISRA-C:TOOL SUPPORT
192
[electronicdesign.com]
193. PT 15/16
Design of Software for
Embedded Systems (SWES)
SOME MISRA-C RULES
• No nested comments
• Inline functions instead of function macros
• No direct comparison of floating points
• No pointer arithmetic, no octals
• No recursion
• Memory shall only be freed if allocated by the
application itself
• Use of typedef’s (with size and signedness)
instead of basic types
193
/*
... pages later...
foo();
/* ... */
... pages later...
*/
void fn ( void )
{
int32_t a;
free(&a);
}
line_a |= 256; /* sets bit nr. 8 */
line_b |= 128; /* sets bit nr. 7 */
line_c |= 064; /* wrongly sets bits 2,4 and 5 */
194. PT 15/16
Design of Software for
Embedded Systems (SWES)
MISRA-CVARIABLES
• All variables shall have a defined value before being used
• No unused variables
• No non-volatile variables with only one use
• Variables may be undefined (U), defined (D), or referenced (R)
• UR anomaly: Initialization required
• DU anomaly: Set and discard
• DD anomaly: No read between two assignments
194
Data Flow Anomalies
● 3 states of a variable are distinguished:
U (undefined), D (defined) and R (referenced)
● Transitions: U discard, D set, R read
● Finite automaton
● UR anomaly: Initialization required; rule 8-5-1
● DU anomaly: Set and discard; 0-1-3 and 0-1-4
● DD anomaly: No read between two assignments
U
R D
U
U anomaly
D
R
U
R
DU
D
R
195. PT 15/16
Design of Software for
Embedded Systems (SWES)
CODE GENERATION
• Some MISRA-C rules less reasonable for generated code
• „No use of compiler-specific language extensions“
• Tries to ensure portable C Code
• No need when C code is just an intermediate language
• „Wrap assembler code in C functions“
• Avoids erroneous utilization of macros in manual coding
• Destroys performance advantage from inline assembler
• „No pointer arithmetic“
• Code generator can be expected to work correctly here
• Some rules can be enforced on model level instead (e.g. no recursion)
195
196. PT 15/16
Design of Software for
Embedded Systems (SWES)
MISRA-C CRITICISM
• Experienced embedded C developers not always agree to MISRA-C
• Rules try to protect from inexperienced C programmers
• Those people shouldn’t write safety-critical code anyway !
• Micro-controller programming needs to deal with scare resources
• goto can save a lot of resources, but is not allowed
• Recursion can save a lot of resources, but is not allowed
• Pointer arithmetic is very efficient, and even used in OS kernels
• Dynamic memory allocation is not allowed, waste of resources
• No stdio.h allowed, but may be useful
196
http://www.knosof.co.uk/misracom.html
197. PT 15/16
Design of Software for
Embedded Systems (SWES)
MISRA-C RELEVANCE
197
“Nonetheless, it should be recognized that there are other
languages available which are in general better suited to
safety-related systems, having (for example) fewer
insecurities and better type checking. Examples of languages
generally recognized to be more suitable than C are Ada
and Modula 2. If such languages could be available for a
proposed system then their use should be seriously
considered in preference to C.“
Source:
“MISRA-C:1998 - Guidelines for the use of the C language in vehicle based software“