Design of Software for Embedded Systems

ENTWURFVON SOFTWARE  
FÜR EINGEBETTETE SYSTEME (SWES) 
DESIGN OF SOFTWARE  
FOR EMBEDDED SYSTEMS (SWES)
Dr. PeterTröger
Operating Systems Group,TU Chemnitz

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 ﬁnal 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

PT 15/16
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

BASIC CONCEPTS AND
TERMINOLOGY
DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES)
Dr. PeterTröger

PT 15/16
EMBEDDED SYSTEM
• Computer system in a context
• Speciﬁc 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 efﬁciency
• Everywhere: Cell phones, printer,s automobiles, aviation products,
household devices, medical devices, children toys, …
5

PT 15/16
EMBEDDED SYSTEMS
6
[http://didik.blog.undip.ac.id/]

PT 15/16
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

PT 15/16
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 ﬁrmware errors
• New cars with > 20 electronic control units (ECU), 
1GB of software in premium car
8

PT 15/16
PROBLEM AREAS
9
Hardware
Software
Non-functionalproperties

PT 15/16
HARDWARE
10
Desired functionality
General purpose Application-speciﬁc Single-purpose

PT 15/16
HARDWARE
11
General purpose Application-speciﬁc Single-purpose
[Vahid/Givargis]

PT 15/16
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

PT 15/16
FLEXIBLE OR EFFICIENT?
13
[Altera]

PT 15/16
HARDWARE
14
General purpose
Application-
speciﬁc
Single purpose
Programmable in Software Hardware Software -
Performance low medium medium high
Energy Efﬁciency 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

PT 15/16
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

PT 15/16
• 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

PT 15/16
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]

PT 15/16
• 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]

PT 15/16
• Field Programmable Gate Arrays (FPGA)
• Reconﬁgurable 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 reconﬁgurable computing
19

PT 15/16
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 ﬁxed point arithmetics (faster)
• Real-time requirements (mostly soft RT), no multitasking
• Multimedia applications (image and audio processing)
• Cryptography
• Programmable in software
20

PT 15/16
SINGLE PURPOSE CHIP
• Application-speciﬁc
integrated circuit
(ASIC)
• Hardware device for
being used in one
product
• Application-speciﬁc
standard part
(ASSP)
• ASIC for re-use in
multiple products
(e.g. USB host
controller)
21
[xilink.com]

PT 15/16
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]

PT 15/16
SYSTEM ON CHIP
• System on chip (SoC)
• Combines functional blocks (‚IP cores‘) in one large IC
• CPU, ROM, RAM, ﬂash, 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

PT 15/16
EXAMPLE:APPLE IPHONE 6
24
[techinsights.com]

PT 15/16
25
[techinsights.com]

PT 15/16
26
[techinsights.com]

PT 15/16
EXAMPLE:APPLE A8 SOC
27
[www.anandtech.com]

PT 15/16
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]

PT 15/16
PROBLEM AREAS
29
Hardware
Software

PT 15/16
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

PT 15/16
Controlled Process
TYPICAL STRUCTURE
31
Sensors
Controller
Software
Clock
Operator
Environment
Actuators Display

PT 15/16
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

PT 15/16
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

PT 15/16
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. ﬂying airplane
34

PT 15/16
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

PT 15/16
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

PT 15/16
SOFT REAL-TIME
37
Release
Time
Scheduling
Time
Completion
time
t
0
Absolute
Deadline
Tardiness
Relative Deadline
Execution Time
Response Time

PT 15/16
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

PT 15/16
REAL-TIME SCHEDULING
• Scheduling: Deﬁne 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

PT 15/16
40
Real-Time Scheduling
Soft
Hard
Dynamic Static
Preemptive Non-Preemptive Preemptive Non-Preemptive

PT 15/16
• ‚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)

PT 15/16
• ‚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

PT 15/16
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

PT 15/16
PROBLEM AREAS
45
Hardware
Software

PT 15/16
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

PT 15/16
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

PT 15/16
DEPENDABILITYTREE [LAPRIE]
48

PT 15/16
THREATS
• System failure - ,Ausfall‘
• Event that occurs when the service no longer complies with the speciﬁcation
/ deviates from the correct service.
• System error - ,Fehler(zustand)‘
• Part of system state that can lead to subsequent failure
• Some sources deﬁne 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

PT 15/16
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

PT 15/16
FAULT MODEL
• Faults can be classiﬁed 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

PT 15/16
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 speciﬁcation
• Performance failures - performance or SLA speciﬁcations not met
• Scope of the failure
• Partial failure - only parts of the system become unavailable
• Total failure - all services go down
52

PT 15/16
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

PT 15/16
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

PT 15/16
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

PT 15/16
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

PT 15/16
EXAMPLE: DO-178D
57

PT 15/16
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, …)

PT 15/16
PROBLEMS AREAS
59
Hardware
Software
• 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

CONTROLTHEORY
Dr. PeterTröger

PT 15/16
Controlled Process
EMBEDDED SYSTEM
61
Sensors
Controller
Software
Clock
Operator
Environment
Actuators Display

PT 15/16
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 speciﬁc 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

PT 15/16
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

PT 15/16
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

PT 15/16
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]

PT 15/16
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!

PT 15/16
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!

PT 15/16
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

PT 15/16
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 identiﬁable
Valve is opened and closed to 
bring controlled variable and 
reference variable together
[Siemens]

PT 15/16
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 (ﬂuctuating 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]

PT 15/16
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
• Modiﬁcation of controller through self-feedback
• Example: Flying missile with decreasing fuel mass
71

PT 15/16
STABILITY
• Control loop is an oscillatory system
• Controlled and manipulated variable inﬂuence each other
• System therefore may escalate into instability
• Bounded input / bounded output (BIBO) stability
• Output signal should not grow indeﬁnitely 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

PT 15/16
CONTROL QUALITY
• Places of disturbance may vary
• Inﬂuence 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

PT 15/16
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]

PT 15/16
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

PT 15/16
PROPORTIONAL ELEMENT
• Output is proportional
to the current error
• Gain factor too low: 
Reaction not good
enough to ﬁx the error
• Gain factor too high: 
Reaction to error is too
extreme (stability)
• Only instantaneous
reaction, therefore
steady-state error
76

PT 15/16
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]

PT 15/16
INTEGRAL ELEMENT
• Output is proportional to
past error behavior
• Delayed reaction to
accumulated errors
• Can ﬁx steady-state error
resulting from
proportional reaction
• May produce output that
exceeds the target 
(overshoot)
78

PT 15/16
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

PT 15/16
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

PT 15/16
• 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]

PT 15/16
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, inﬂuence
reduces and P+I parts are
‚taking over‘
82

PT14/15
PID CONTROLLER
• Initial charge by D
• Reduction almost to P level
• Rises again from I inﬂuence
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

PT14/15
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 ﬁnal value
• Settling time -  
How fast settling into some range around the ﬁnal value
84

PT 15/16
DIGITAL PID CONTROLLER
• Digital microcontrollers implement control function
• Easier realization of non-linear behavior and adaptive control
• Reconﬁguration 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
• Overﬂow 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

PT 15/16
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

Design of Software for Embedded Systems
WS15/16
Chair of Operating Systems
Jafar Akhundov
Mathematical Theory of Systems
and Control
Chapter 3

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
Chapter 3: Mathematical Theory of Systems and Control
88

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
89

1.1 Control System Definition (refreshment)
WS15/16
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]

Input Command
2
1
Example: Elevator
WS15/16
91
t
h
Elevator Response
Steady-state
error
Transient
Response
Source: [2]

1.2 Open-Loop vs. Closed-Loop (refreshment)
Open-Loop
▶ Stable
▶ No feedback
▶ Not precise
▶ Cannot compensate disturbances
▶ Simple
▶ Cheap
WS15/16
92
Closed-Loop
▶ Can become unstable
▶ Has a feedback loop
▶ Precise
▶ Compensates disturbances
▶ Complex
▶ Expensive

1.3 Objectives of Analysis and Design
▶ Three major goals:
▶ Producing the desired transient response
▶ Reducing steady-state error
▶ Achieving Stability
WS15/16
93
Deﬁnition: 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]

Control System Design Process: Overview
WS15/16
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]

Control System Design Process: Stages
WS15/16
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]

Control System Design Process: Stages (2)
WS15/16
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]

Control System Design Process: Stages (3)
WS15/16
97
6.Analyze and Design
1.Mostly testing and veriﬁcation
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]

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
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]

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
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]

2.2 Differential Equations (refreshment)
WS15/16
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]

WS15/16
101
▶ Example (Newton's Second Law):
F = ma
F = m
d2
x
dt2
Deﬁnition: 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 ﬁrst power.
Source: [3]

WS15/16
102
Deﬁnition: 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]

2.3 Laplace Transform
WS15/16
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.
Deﬁnition: The Laplace transform is deﬁned 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

2.3 Laplace Transform Simple Example
WS15/16
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]

2.3 Laplace Transform table
WS15/16
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
...

2.3 Laplace Transform Another Example
WS15/16
107
▶ 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]

2.3 Laplace Transform Complex Example
WS15/16
108
▶ 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]

2.3 Inverse Laplace Transform
WS15/16
109
Deﬁnition: The inverse Laplace transform is deﬁned 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]

2.3 Partial-Fraction Expansion
WS15/16
110
▶ Problem: how to ﬁnd 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 fulﬁlled
▶ 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]

2.3 Partial-Fraction Expansion (Case 1)
WS15/16
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 ﬁnd , 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]

2.3 Partial-Fraction Expansion (Case 2)
WS15/16
112
▶ Case 2: Roots of denominator are real and repeated
▶ To ﬁnd 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]

2.3 Using Laplace Transform To Solve Linear ODE
WS15/16
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]

2.3 Using Laplace Transform To Solve Linear ODE
WS15/16
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]

3.1 Transfer Functions
WS15/16
115
▶ It is now possible for us to give a deﬁnition 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]

3.1 Transfer Functions - Example
WS15/16
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]

3.2 Mechanical Translational Transfer Functions
WS15/16
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]

http://osg.informatik.tu-chemnitz.deWS15/16
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]

Summary of the last lecture
WS15/16
▶ 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

3.3 Block diagrams
WS15/16
▶ 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

3.3 Cascade Form of Transfer Functions
WS15/16
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) =

3.3 Parallel Form of Transfer Functions
WS15/16
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]

3.3 Feedback Form of Transfer Functions
WS15/16
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]

3.3 Restructuring Topologies (Summing Junction)
WS15/16
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)

3.3 Restructuring Topologies (Summing Junction)
WS15/16
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]

3.3 Example
WS15/16
126
▶ Problem: reduce the block diagram and ﬁnd the transfer function of the system:
Source: [2]
R(s) + C(s)
G1(s) G2(s)
H2(s)
H1(s)
H3(s)
G3(s)
+
+ +

3.3 Example
WS15/16
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]

3.3 Example
WS15/16
128
▶ Steps 2&3: use cascade, parallel and feedback forms to get the ﬁnal 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]

4. Time Response
WS15/16
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

4.1 Poles and Zeros
WS15/16
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)

4.1 Poles and Zeros Example
WS15/16
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

4.2 First-Order Systems
WS15/16
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:

4.2 First-Order Systems Characteristics
WS15/16
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

4.2 First-Order Systems Characteristics
WS15/16
134
Source: [2]
Ts
t
c(t)
a=2
Tr

4.3 Second-Order Systems
WS15/16
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

4.3 Second-Order Systems Types (1)
WS15/16
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

WS15/16
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

WS15/16
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

4.3 General Second-Order System
WS15/16
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

4.3 General Second-Order System
WS15/16
140
Source: [2]
Response
Type
Undamped
Underdamped
Critically
Damped
Overdamped
⇠
⇠ = 0
0 < ⇠ < 1
⇠ = 1
⇠ > 1

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.

5. System Stability Analysis
WS15/16
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
Deﬁnition(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.
Deﬁnition: 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.

WS15/16
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.

WS15/16
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

5. Informal System Stability Analysis: Example 1
WS15/16
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 ﬁnd TF and solve!

5. Informal System Stability Analysis: Example 2
WS15/16
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 ﬁnd TF and solve!

5. Informal System Stability Analysis: Problem
WS15/16
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 ﬁnd the roots
▶ Or use other techniques to analyse for stability, e.g. Routh-Hurwitz method

6. PID-Tuning
WS15/16
148
▶ How to determine optimal values for PID-controller?
▶ Depends on deﬁnition of optimality
▶ Possible goals:
• Stability
• Minimum overshoot
• Damped noise
• Minimum steady-state error
• Short settling time

6. Ziegler-Nichols Method for PID-Tuning
WS15/16
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 indeﬁnitely 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

References
WS15/16
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.

C
Dr. PeterTröger

PT 15/16
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 efﬁcient => 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

PT 15/16
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; 
}

PT 15/16
TECHNICAL ENVIRONMENT
154
Code / 
Model
Compiler
Object ﬁle for target
Remote debugger
Terminal
HW debugging support
SW outputs
Developer PC Embedded system
JTAG
Serial
Executed code
Transfer

PT 15/16
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

PT 15/16
C HEADER FILES
156
#ifndef __LINUX_GPIO_H 
#define __LINUX_GPIO_H
#define GPIOF_DIR_OUT (0 << 0) 
#define GPIOF_DIR_IN (1 << 0) 
#define GPIOF_INIT_LOW (0 << 1) 
#define GPIOF_INIT_HIGH (1 << 1) 
#define GPIOF_IN (GPIOF_DIR_IN) 
#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW) 
#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
#ifdef CONFIG_GENERIC_GPIO 
#include <asm/gpio.h> 
#else 
#include <linux/kernel.h> 
#include <linux/types.h> 
#include <linux/errno.h> 
struct device; 
struct gpio; 
struct gpio_chip; 
... 
#endif
#endif

PT 15/16
C STATEMENTS
• Statement syntax has inﬂuenced 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

PT 15/16
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

PT 15/16
64 BIT DATA MODELS
160
[Wikipedia]

PT 15/16
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

PT 15/16
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 ﬂow of the program (e.g. by hardware)
162

PT 15/16
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)) {;} 
}

PT 15/16
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];

PT 15/16
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; 
}

PT 15/16
ARRAYS AND POINTERS
• Value of an array variable is the address
of the ﬁrst 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 ﬁrst 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]);

PT 15/16
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++; } 
}

PT 15/16
ARRAYS AND POINTERS
• Pointers can be added, subtracted and compared
• Pointer arithmetics - very efﬁcient 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 overﬂow attack on return address)
• Pointer can reference functions (start address in code segment)
168
(* compare) ( ”hello”, ”world” );

PT 15/16
BUFFER OVERFLOW
169
Local variables of main()
Free
Code, 
main() calling foo()
Code,
foo() running
Return address
Local variables of foo()
Free
Code, 
foo() running
Return address
Local variables of foo()
Free
SP
SP
Overﬂow
0x0000...

PT 15/16
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 ﬁxed-size index variable
170

PT 15/16
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

PT 15/16
DEPENDABLE C CODE
• Low-level approach makes C code fast and memory-efﬁcient
• 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

PT 15/16
DEPENDABLE C CODE
• Problematic properties of the C language
• Intentionally implementation-deﬁned behavior
• Examples:  
Expression evaluation order, numerical types, register type
• Chance for compiler optimizations
• Intentionally non-portable semantics
• Example: LOCALE in character / string handling
• Intentionally undeﬁned behavior
• Example: Reaction on run-time problems,  
such as non-initialized variables being used
173

PT 15/16
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

PT 15/16
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]

PT 15/16
IOCCC.ORG
176
http://ioccc.org/years-spoiler.html

PT 15/16
C STYLE GUIDES
177

PT 15/16
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++; 
}

PT 15/16
FUNCTION MACROS
• Code considers
platform speciﬁcs on
memory copy
operation
• memcpy()
function may be
implemented by a
preprocessor macro
• Compiler behavior
undeﬁned
• Either re-formulate
code or forbid
function macros
179
[https://www.securecoding.cert.org/]

PT 15/16
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

PT 15/16
TYPE CONVERSIONS
• Handle down-cast of
values explicitly
181

PT 15/16
POINTERS
• getenv documentation
declares that returned
pointer should not be
stored
• Code may lead to
overwriting of ﬁrst result
• Variables are considered
the same even though
they are not
• ‚Heisenbug‘
182

PT 15/16
COMMENTING
• Code implements an algorithm
• High-level comments for major software modules
• Fine granularity comments explaining non-obvious details
• Header ﬁles 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)  
*******************************************************************/

PT 15/16
COMMENTING
184
[freescale.com]

PT 15/16
DATATYPES
• Typical example for
memory-mapped I/O
• Compiler determines
offsets for individual
registers
• Allows struct-
based access
• struct deﬁnition
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) 
{ ... }

PT 15/16
DATATYPES
• Same single-line instruction on different processors
• Choice of data type impacts assembler code efﬁciency
• Trade-off between optimal portability and optimal performance
186
[freescale.com]

PT 15/16
DATATYPES
• Raw C data types allows compiler to choose most efﬁcient storage 
 
• Most coding conventions recommend to not use them
• Projects deﬁne their own data type abstractions
• <stdint.h> for C99 provides portable data types
• int8_t: signed 8-bit uint8_t: unsigned 8-bit
187
for (int i=0; i < N; i++) { ... }

PT 15/16
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

PT 15/16
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 deﬁne
constant objects instead
189
const int x=1;
void f(int& x); 
// ... 
const int i; 
f(i);
int const *px;
int * const px;

PT 15/16
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

PT 15/16
MISRA-C RULES
• Categories of problems being tackled
• Common programming errors in C
• Underspeciﬁed 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

PT 15/16
MISRA-C:TOOL SUPPORT
192
[electronicdesign.com]

PT 15/16
SOME MISRA-C RULES
• No nested comments
• Inline functions instead of function macros
• No direct comparison of ﬂoating 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 */

PT 15/16
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

PT 15/16
CODE GENERATION
• Some MISRA-C rules less reasonable for generated code
• „No use of compiler-speciﬁc 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

PT 15/16
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 efﬁcient, 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

PT 15/16
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“

Design of Software for Embedded Systems

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Design of Software for Embedded Systems

Ähnlich wie Design of Software for Embedded Systems (20)

Mehr von Peter Tröger

Mehr von Peter Tröger (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Design of Software for Embedded Systems