Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Design of Software for Embedded Systems

1.309 Aufrufe

Veröffentlicht am

The course covers basic principles of software design and development for embedded systems, with a special emphasis on automotive systems. Topics included in the slide deck are:

- Introduction and basic concepts
- Functional and non-functional requirements on embedded software
- Real-time execution environments and operating systems
- Programming languages and middleware for embedded systems
- Model-driven development for embedded systems
- Latest trends from research and practice

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

Design of Software for Embedded Systems

  1. 1. ENTWURFVON SOFTWARE 
 FÜR EINGEBETTETE SYSTEME (SWES)
 DESIGN OF SOFTWARE 
 FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
  2. 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. 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
  4. 4. BASIC CONCEPTS AND TERMINOLOGY DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
  5. 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. 6. PT 15/16 Design of Software for Embedded Systems (SWES) EMBEDDED SYSTEMS 6 [http://didik.blog.undip.ac.id/]
  7. 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. 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. 9. PT 15/16 Design of Software for Embedded Systems (SWES) PROBLEM AREAS 9 Hardware Software Non-functionalproperties
  10. 10. PT 15/16 Design of Software for Embedded Systems (SWES) HARDWARE 10 Desired functionality General purpose Application-specific Single-purpose
  11. 11. PT 15/16 Design of Software for Embedded Systems (SWES) HARDWARE 11 General purpose Application-specific Single-purpose [Vahid/Givargis]
  12. 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. 13. PT 15/16 Design of Software for Embedded Systems (SWES) FLEXIBLE OR EFFICIENT? 13 [Altera]
  14. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE IPHONE 6 24 [techinsights.com]
  25. 25. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE IPHONE 6 25 [techinsights.com]
  26. 26. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE IPHONE 6 26 [techinsights.com]
  27. 27. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE A8 SOC 27 [www.anandtech.com]
  28. 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. 29. PT 15/16 Design of Software for Embedded Systems (SWES) PROBLEM AREAS 29 Hardware Software Non-functionalproperties
  30. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41. 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)
  42. 42. 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
  43. 43. 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
  44. 44. PT 15/16 Design of Software for Embedded Systems (SWES) PROBLEM AREAS 45 Hardware Software Non-functionalproperties
  45. 45. 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
  46. 46. 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
  47. 47. PT 15/16 Design of Software for Embedded Systems (SWES) DEPENDABILITYTREE [LAPRIE] 48
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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
  56. 56. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE: DO-178D 57
  57. 57. 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, …)
  58. 58. 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
  59. 59. CONTROLTHEORY DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
  60. 60. PT 15/16 Design of Software for Embedded Systems (SWES) Controlled Process EMBEDDED SYSTEM 61 Sensors Controller Software Clock Operator Environment Actuators Display
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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]
  65. 65. 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!
  66. 66. 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!
  67. 67. 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
  68. 68. 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]
  69. 69. 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]
  70. 70. 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
  71. 71. 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
  72. 72. 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
  73. 73. 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]
  74. 74. 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
  75. 75. 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
  76. 76. 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]
  77. 77. 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
  78. 78. 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
  79. 79. 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
  80. 80. 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]
  81. 81. 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
  82. 82. 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
  83. 83. 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
  84. 84. 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
  85. 85. 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
  86. 86. 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
  87. 87. 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
  88. 88. 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
  89. 89. 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]
  90. 90. Input Command 2 1 http://osg.informatik.tu-chemnitz.de Example: Elevator WS15/16 Design of Software for Embedded Systems Chapter 3: Mathematical Theory of Systems and Control 91 t h Elevator Response Steady-state error Transient Response Source: [2]
  91. 91. 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
  92. 92. 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]
  93. 93. 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]
  94. 94. 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]
  95. 95. 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]
  96. 96. 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]
  97. 97. 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]
  98. 98. 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]
  99. 99. 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]
  100. 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 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]
  101. 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 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]
  102. 102. 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
  103. 103. 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]
  104. 104. 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 ...
  105. 105. 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) ...
  106. 106. 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]
  107. 107. 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]
  108. 108. 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]
  109. 109. 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]
  110. 110. 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]
  111. 111. 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]
  112. 112. 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]
  113. 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 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]
  114. 114. 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]
  115. 115. 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]
  116. 116. 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]
  117. 117. 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]
  118. 118. 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
  119. 119. 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
  120. 120. 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) =
  121. 121. 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]
  122. 122. 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]
  123. 123. 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)
  124. 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 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]
  125. 125. 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) + + +
  126. 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 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]
  127. 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 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]
  128. 128. 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
  129. 129. 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)
  130. 130. 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
  131. 131. 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:
  132. 132. 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
  133. 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 134 Source: [2] Ts t c(t) a=2 Tr
  134. 134. 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
  135. 135. 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
  136. 136. 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
  137. 137. 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
  138. 138. 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
  139. 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 140 Source: [2] Response Type Undamped Underdamped Critically Damped Overdamped ⇠ ⇠ = 0 0 < ⇠ < 1 ⇠ = 1 ⇠ > 1
  140. 140. 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.
  141. 141. 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.
  142. 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 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.
  143. 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 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
  144. 144. 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!
  145. 145. 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!
  146. 146. 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
  147. 147. 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
  148. 148. 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
  149. 149. 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.
  150. 150. C DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
  151. 151. 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
  152. 152. 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;
 }
  153. 153. 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
  154. 154. 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
  155. 155. PT 15/16 Design of Software for Embedded Systems (SWES) 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
  156. 156. 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
  157. 157. 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
  158. 158. [Wikipedia]
  159. 159. PT 15/16 Design of Software for Embedded Systems (SWES) 64 BIT DATA MODELS 160 [Wikipedia]
  160. 160. 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
  161. 161. 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
  162. 162. 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)) {;}
 }
  163. 163. 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];
  164. 164. 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;
 }
  165. 165. 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]);
  166. 166. 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++; }
 }
  167. 167. 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” );
  168. 168. 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...
  169. 169. 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
  170. 170. 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
  171. 171. 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
  172. 172. 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
  173. 173. 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
  174. 174. 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]
  175. 175. PT 15/16 Design of Software for Embedded Systems (SWES) IOCCC.ORG 176 http://ioccc.org/years-spoiler.html
  176. 176. PT 15/16 Design of Software for Embedded Systems (SWES) C STYLE GUIDES 177
  177. 177. 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++;
 }
  178. 178. 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/]
  179. 179. 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/]
  180. 180. PT 15/16 Design of Software for Embedded Systems (SWES) TYPE CONVERSIONS • Handle down-cast of values explicitly 181 [https://www.securecoding.cert.org/]
  181. 181. 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/]
  182. 182. 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) 
 *******************************************************************/
  183. 183. PT 15/16 Design of Software for Embedded Systems (SWES) COMMENTING 184 [freescale.com]
  184. 184. 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)
 { ... }
  185. 185. 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]
  186. 186. 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++) { ... }
  187. 187. 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
  188. 188. 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;
  189. 189. 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
  190. 190. 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
  191. 191. PT 15/16 Design of Software for Embedded Systems (SWES) MISRA-C:TOOL SUPPORT 192 [electronicdesign.com]
  192. 192. 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 */
  193. 193. 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
  194. 194. 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
  195. 195. 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
  196. 196. 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“

×