SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.

SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.

Diese Präsentation wurde erfolgreich gemeldet.

Diese Präsentation gefällt Ihnen? Dann am besten gleich teilen!

- Embedded Systems: Future trends, Em... by Career Communicat... 663 views
- Design of embedded systems by Dr. Pradeep Kumar... 16802 views
- ppt on embedded system by manish katara 142385 views
- Droidcon 2013 france - The Growth o... by Benjamin Zores 2843 views
- DESIGN CHOICES FOR EMBEDDED REAL-TI... by FPGA Central 3974 views
- Embedded Software and Tools Market ... by VDC Research Group 9075 views

1.309 Aufrufe

Veröffentlicht am

- 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

Keine Downloads

Aufrufe insgesamt

1.309

Auf SlideShare

0

Aus Einbettungen

0

Anzahl an Einbettungen

1

Geteilt

0

Downloads

142

Kommentare

0

Gefällt mir

6

Keine Einbettungen

Keine Notizen für die Folie

- 1. ENTWURFVON SOFTWARE FÜR EINGEBETTETE SYSTEME (SWES) DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
- 2. PT 15/16 Design of Software for Embedded Systems (SWES) COURSE ORGANIZATION • Weekly lectures (starting today) + tutorials (starting next week) • 5 assignment sheets, minimum of 50% of all points needed • OPAL: News, slides (after lecture !), discussion forum, time plans • Written ﬁnal exam • Module 565050 (adopted from Dr. habil. D. Müller) • Basic concepts and terminology • Control theory for practitioners • Programming for embedded systems in C and Ada • Model-driven development for embedded systems, PLC systems • Safety and security standards 2
- 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. BASIC CONCEPTS AND TERMINOLOGY DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
- 5. PT 15/16 Design of Software for Embedded Systems (SWES) EMBEDDED SYSTEM • Computer system in a context • Speciﬁc dedicated task (vs. all-purpose computer) • Often hardware/software co-design • Optimize design based on application characteristics • Often non-visible for user • Often real-time systems (max. response time ≤ deadline) • High cost pressure - low memory size, simple CPUs • Energy efﬁciency • Everywhere: Cell phones, printer,s automobiles, aviation products, household devices, medical devices, children toys, … 5
- 6. PT 15/16 Design of Software for Embedded Systems (SWES) EMBEDDED SYSTEMS 6 [http://didik.blog.undip.ac.id/]
- 7. PT 15/16 Design of Software for Embedded Systems (SWES) SOFTWARE FOR EMBEDDED SYSTEMS • Ebert and Jones, 2009 • Worldwide market of 160 billion € • ~30 embedded processors per person in developed countries • 98% of all produced microprocessors for embedded applications 7
- 8. PT 15/16 Design of Software for Embedded Systems (SWES) CHALLENGES • How to minimize power consumption and costs ? • Amount and type of hardware needed • Power-aware software and operating systems • How can you interact with the physical world ? • Hardware sensors and actuators • Real-time software constraints • How to ensure non-functional properties ? • 1990-2000: 40% of recalled pacemakers due to ﬁrmware errors • New cars with > 20 electronic control units (ECU), 1GB of software in premium car 8
- 9. PT 15/16 Design of Software for Embedded Systems (SWES) PROBLEM AREAS 9 Hardware Software Non-functionalproperties
- 10. PT 15/16 Design of Software for Embedded Systems (SWES) HARDWARE 10 Desired functionality General purpose Application-speciﬁc Single-purpose
- 11. PT 15/16 Design of Software for Embedded Systems (SWES) HARDWARE 11 General purpose Application-speciﬁc Single-purpose [Vahid/Givargis]
- 12. PT 15/16 Design of Software for Embedded Systems (SWES) HARDWARE • General-purpose hardware • Main goal is ﬂexible usage with best-possible performance • Programmable for all use cases • Application-speciﬁc 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 ﬁxed in hardware 12
- 13. PT 15/16 Design of Software for Embedded Systems (SWES) FLEXIBLE OR EFFICIENT? 13 [Altera]
- 14. PT 15/16 Design of Software for Embedded Systems (SWES) HARDWARE 14 General purpose Application- speciﬁc Single purpose Programmable in Software Hardware Software - Performance low medium medium high Energy Efﬁciency low medium medium high Feature Flexibility very high medium low very low Per unit price savings low low medium very high Example Microprocessor PLD / FPGA DSP ASIC / ASSP
- 15. PT 15/16 Design of Software for Embedded Systems (SWES) GENERAL PURPOSE CHIP • Microprocessor: Multi- purpose, programmable device • Central Processing Units (CPUs) + volatile memory + I/ O devices 15 [Stallings] • Fetch instruction and execute it - typically memory access, computation, and / or I/O • I/O devices and memory controller may interrupt the instruction processing
- 16. PT 15/16 Design of Software for Embedded Systems (SWES) GENERAL PURPOSE CHIP • RISC - Reduced Instruction Set Computer • MIPS,ARM, DEC Alpha, Sparc, IBM 801, Power, etc. • Small number of instructions, few data types in hardware • Instruction size constant, few addressing modes • Relies on optimization in software • CISC - Complex Instruction Set Computer • VAX, Intel X86, IBM 360/370, etc. • Large number of complex instructions, may take multiple cycles • Variable length instructions, smaller code size • Focus on optimization in hardware • RISC designs lend themselves to exploitation of instruction level parallelism 16
- 17. PT 15/16 Design of Software for Embedded Systems (SWES) ARM • ARM design started in 1983 by Acorn Computers Ltd. Roger Wilson and Steve Furber • 1990 renamed to Advanced RISC Machines Ltd., 1998 renamed to ARM Ltd. • 32-Bit and 64-Bit RISC processor architecture • ARM does not manufacture itself, licenses to others:ATMEL, Intel, IBM, Nintendo, ... • ARM targets low-power and low-cost embedded applications 17 [enterprisetech.com]
- 18. PT 15/16 Design of Software for Embedded Systems (SWES) GENERAL PURPOSE CHIP • Programmable logic device (PLD) • Type of semiconductor hardware that can be „re-wired“ after production 18 [TyGaribay,Altera] FPGA Design Cost 3.200.000 $ FPGA Starting Unit Price 4x375 $ = 1500 $ ASIC Design Cost 85.000.000 $ ASIC Starting Unit Price 400 $ ASIC market delay 3 months Early entry device volume 49 % Processor Blade Example [Xilink]
- 19. PT 15/16 Design of Software for Embedded Systems (SWES) GENERAL PURPOSE CHIP • Field Programmable Gate Arrays (FPGA) • Reconﬁgurable technology • Hardware (!) functionality can be changed • Errors can be corrected/masked • Very short development times, suitable for low number of units • Hardware description languages:VHDL andVerilog • May be used to validate ASIC design • SRAM- and Flash-based FPGAs allow reconﬁgurable computing 19
- 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 ﬁxed point arithmetics (faster) • Real-time requirements (mostly soft RT), no multitasking • Multimedia applications (image and audio processing) • Cryptography • Programmable in software 20
- 21. PT 15/16 Design of Software for Embedded Systems (SWES) SINGLE PURPOSE CHIP • Application-speciﬁc integrated circuit (ASIC) • Hardware device for being used in one product • Application-speciﬁc standard part (ASSP) • ASIC for re-use in multiple products (e.g. USB host controller) 21 [xilink.com]
- 22. PT 15/16 Design of Software for Embedded Systems (SWES) MICROCONTROLLER • Integrated circuit with processor, memory, and I/O hardware (µC, uC, MCU) • Example:Atmel AT89S8253 8-bit microcontroller • MCS 51 instruction set • 12 kByte Flash memory, 2 kByte EEPROM data memory • 256 x 8 Bit internal RAM • 32 programmable I/O lines • UART serial port • Three 16-bit timers • 2.7V - 5.5V operating range • Power saving mode 22 [mikroe.com]
- 23. PT 15/16 Design of Software for Embedded Systems (SWES) SYSTEM ON CHIP • System on chip (SoC) • Combines functional blocks (‚IP cores‘) in one large IC • CPU, ROM, RAM, ﬂash, Ethernet, Bluetooth, audio, USB, time, voltage, … • Soft-IP-Core in hardware description language (Verilog,VHDL) • Can be parameterized (cache sizes, bus sizes, …), see opencores.org • Licensed by companies such as ARM and MIPS • Hard-IP-Core already built or integrated in FPGA • Replace multi-chip setup, reduces power and space demands • Typically with debugging interface (JTAG, USB) 23
- 24. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE IPHONE 6 24 [techinsights.com]
- 25. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE IPHONE 6 25 [techinsights.com]
- 26. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE IPHONE 6 26 [techinsights.com]
- 27. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE:APPLE A8 SOC 27 [www.anandtech.com]
- 28. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE: RASPBERRY PI • Broadcom BCM2835 SoC • ARM11 processor • Videocore 4 GPU • General purpose I/O (GPIO) pins • Audio, USB, HDMI, I2C, UART • Timers • Interrupt controller 28 [raspberrypi.org]
- 29. PT 15/16 Design of Software for Embedded Systems (SWES) PROBLEM AREAS 29 Hardware Software Non-functionalproperties
- 30. PT 15/16 Design of Software for Embedded Systems (SWES) EMBEDDED SOFTWARE • Embedded software interacts with the physical world • Often written by domain experts, not computer scientists • Timeliness becomes more important (e.g. deadlines) • Concurrency becomes more important (e.g. physical events) • Liveness becomes crucial (e.g. deadlock prevention) • Heterogeneity becomes default • In general: Predictable behavior, from nice-to-have to mission-critical 30 http://ptolemy.eecs.berkeley.edu/publications/papers/02/embsoft/embsoftwre.pdf
- 31. PT 15/16 Design of Software for Embedded Systems (SWES) Controlled Process TYPICAL STRUCTURE 31 Sensors Controller Software Clock Operator Environment Actuators Display
- 32. PT 15/16 Design of Software for Embedded Systems (SWES) STARTING POINT 32 • Understanding of resources • Describe resources available to the application (CPU, memory, OS) • Driven by cost factors and environmental conditions • Understanding of algorithms • Which resources will be used in which way • Relevant resulting performance metrics • Understanding of workload • Must consider control and data dependencies • Driven by environmental conditions • Describe tasks to be handled + timeliness constraints
- 33. PT 15/16 Design of Software for Embedded Systems (SWES) TIMELINESS • Embedded systems are often real-time systems • Hard real-time systems are often embedded systems “A real-time system is one in which the correctness of the computations not only depends on the logical correctness of the computation, but also on the time at which the result is produced (deadline). If the timing constraints of the system are not met, system failure is said to have occurred.” • Autopilot in airplane vs. YouTube video player • Position calculation vs. 30 images / s • Do all tasks have to be executed before their deadline ? • How to deal with missed deadlines ? • When is the result produced ? 33
- 34. PT 15/16 Design of Software for Embedded Systems (SWES) REAL-TIME • Hard real-time: Missing a deadline is not acceptable • Aircraft control systems • Nuclear power / chemical plant safety mechanisms • Medical devices • Soft real-time: Missing a deadline is undesirable • Multimedia • Airline reservation • High-speed trading applications • Real-time objectives may change during operation • Example: Grounded airplane vs. ﬂying airplane 34
- 35. PT 15/16 Design of Software for Embedded Systems (SWES) TASK /VALUE FUNCTIONS 35 Value deadline Value deadline Value deadline Value deadline Value deadline Value deadline Value deadline Value deadline Value deadline • Deadline missed • Hard real-time:Task result has no more value • Soft real-time:Task result has reduced value
- 36. PT 15/16 Design of Software for Embedded Systems (SWES) HARD REAL-TIME 36 Release Time Scheduling Time Completion time Absolute Deadline Execution Time Relative Deadline Zeitliche Parameter (Timing constraints) eines Jobs. t 0 Response Time
- 37. PT 15/16 Design of Software for Embedded Systems (SWES) SOFT REAL-TIME 37 Release Time Scheduling Time Completion time t 0 Absolute Deadline Tardiness Relative Deadline Execution Time Response Time
- 38. PT 15/16 Design of Software for Embedded Systems (SWES) REAL-TIMETASKS • Periodic tasks • Examples: Sensor data acquisition, action planning, system monitoring • Must be regularly activated (once per period) • Aperiodic tasks • Example: Background services, logging, operator requests • Triggered by well-known event at any time • Sporadic tasks • Example: Collision detection in a roboter, I/O device interrupt • Aperiodic task with minimum inter-arrival time (rate restriction) 38
- 39. PT 15/16 Design of Software for Embedded Systems (SWES) REAL-TIME SCHEDULING • Scheduling: Deﬁne order of task execution • Mature theory for real-time schedules on uniprocessors since 1970’s • Theory for real-time multiprocessor schedules still under research • On small embedded systems (micro-controller scale) • Only one / a few tasks • ‚Manual‘ scheduling by developer good enough • On larger embedded systems • Real-time operating system • Implements appropriate scheduling concepts • Supports prioritization and synchronization of concurrent tasks 39
- 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. 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. 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. 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. PT 15/16 Design of Software for Embedded Systems (SWES) PROBLEM AREAS 45 Hardware Software Non-functionalproperties
- 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. 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. PT 15/16 Design of Software for Embedded Systems (SWES) DEPENDABILITYTREE [LAPRIE] 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 speciﬁcation / deviates from the correct service. • System error - ,Fehler(zustand)‘ • Part of system state that can lead to subsequent failure • Some sources deﬁne errors as active faults - not in this course ... • System fault - ,Fehler(ursache)‘ • Adjudged or hypothesized cause of an error • Failure occurs when error state alters the provided service • Systems are build from connected components, which are again systems • Fault is the consequence of a failure of some other system to deliver its service 49 Fault Error Failure
- 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. PT 15/16 Design of Software for Embedded Systems (SWES) FAULT MODEL • Faults can be classiﬁed into categories on different abstraction levels • Physics • Circuit level / switching circuit level • Interesting for hardware design research (not this course) • Investigate logical signals on connections • stuck-at-zero, stuck-at-one, bridging faults, stuck-open • Register transfer level • Processor-memory-switch (PMS) level • Hardware system level • ... (Software) ... 51
- 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 speciﬁcation • Performance failures - performance or SLA speciﬁcations not met • Scope of the failure • Partial failure - only parts of the system become unavailable • Total failure - all services go down 52
- 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 beneﬁts 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 beneﬁt • Signiﬁcant / 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. 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. 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. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE: DO-178D • Software Considerations in Airborne Systems and Equipment Certiﬁcation • Mature document, developed for more than 20 years • Deﬁnition of severity of failure for airplane, crew, and passengers • Catastrophic - Loss of ability to continue safe ﬂight 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 signiﬁcantly reduced airplane safety, slight increase in workload (Example: Change of ﬂight plan) • No effect - Failure results in no loss of operational capabilities and no increase in crew workload 56
- 56. PT 15/16 Design of Software for Embedded Systems (SWES) EXAMPLE: DO-178D 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. 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. CONTROLTHEORY DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
- 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. 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 speciﬁc implementation details (e.g. car speed control) creates a dedicated mathematical problem • How to consider measured input to control some regulation output • Mathematical principles as glue between engineering disciplines • Everybody has some kind of ‚control problem‘ • Example: Control unit (Steuergerät) in automotive systems 62
- 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. 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. 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. 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. 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. 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. 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 identiﬁable Valve is opened and closed to bring controlled variable and reference variable together [Siemens]
- 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 (ﬂuctuating boiler water temperature) • y - Manipulated variable 70 z1 x2 1 y 4 2 3 5 z2 x1 a b d c w x2 z1 z2 B31-13 w x y 1 x2 [Siemens]
- 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 • Modiﬁcation of controller through self-feedback • Example: Flying missile with decreasing fuel mass 71
- 71. PT 15/16 Design of Software for Embedded Systems (SWES) STABILITY • Control loop is an oscillatory system • Controlled and manipulated variable inﬂuence each other • System therefore may escalate into instability • Bounded input / bounded output (BIBO) stability • Output signal should not grow indeﬁnitely when the input is limited • Mandatory condition for every serious control system 72 4.2.1 Response to interference If, without external intervention, the controlled variable in the control loop fails to assume a constant value even after an infinite period of time since the occurrence of the last interference (sustained oscillation), the term self-excitation is used, and the control loop is said to be unstable. This state must be avoided at all costs by correct adjustment of the controller. In unstable control loops two different types of oscillation can be distinguished – periodically undamped oscillation and periodically excited oscillation: • In the case of periodically undamped oscillation, the amplitude and frequency of the sustained oscillation occurring after occurrence of the interference z are constant (Fig. 4-3). The control element must not travel to either the upper or lower limit position. The time required for one full oscillation is referred to as the period of oscillation TP. The loop gain that gives rise to undamped oscillation in the control loop is referred to as the critical loop gain Vokrit. The proportional band Xp and the transfer coefficient KR KP of the P-controller that produce this undamped oscillation are referred to as Xp krit. and KR KP krit. respectively. TPx t z Fig. 4-3 Undamped oscillation Tp Period of oscillation z Interference of the sustained oscillation that occurs (Fig. 4-4). It occurs if the control loop is set higher than its critical value. x z t Fig. 4-4 Excited oscillation z Interference In practice, the amplitude of oscillation continues to increase as limited by the end stops, e.g. valve fully open or valve closed. In a stable control loop, oscillations of the controlled variable a interference, but their amplitude decreases over time until they d This is referred to as damped oscillation. A steady state, i.e. re (Fig. 4-5). z x t Fig. 4-5 Damped oscillation z Interference A steady state, and therefore rest, occurs if the loop gain VO of t Undamped oscillation Damped oscillation
- 72. PT 15/16 Design of Software for Embedded Systems (SWES) CONTROL QUALITY • Places of disturbance may vary • Inﬂuence on measured output, system input or system output • Control deviation should be minimized over time • Especially relevant for real-time systems 73 Dirk Müller: Design of SW for embedded Sys., Winter term 2013/14 Relationship to RT (2/2) t r Latency or settling time (e.g. until deviation below 3%) y e(t3): here overshoot (as maximum) t3 ∫ t1 t2 ∣r(t)−y(t)∣dt t1 t2 ● Error e and integral give inspiration for first (simple) control path and controller types => P controller and I controller
- 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. 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. 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 ﬁx the error • Gain factor too high: Reaction to error is too extreme (stability) • Only instantaneous reaction, therefore steady-state error 76
- 76. PT 15/16 Design of Software for Embedded Systems (SWES) P CONTROLLER • Example: Mechanical water level control systems • Adjustable inﬂow with valve 1 • Variable outﬂow 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) deﬁned 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. 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 ﬁx steady-state error resulting from proportional reaction • May produce output that exceeds the target (overshoot) 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 ﬂow rate, level remains constant • With increased incoming ﬂow, output ﬂow 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. 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. 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. 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, inﬂuence reduces and P+I parts are ‚taking over‘ 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 inﬂuence 83 [Siemens] As already known, with a D-component, the magnitude of the manipulated variable change is proportional to the rate of change of the controlled variable or control difference. e y P I D PID y a) b) Fig. 3-25 PID-controller a) Model b) Step response P P-component I I-component D D-component The step response of the PID-controller (Fig. 3-25b) co superimposition of the P-component, I-component and shows that an initial large change of the manipulated v element. This means that interference will not give rise The manipulated variable y is then reduced almost to th where it rises again in a linear fashion under the influen the I-component, the PID controller compensates for se disturbances with no residual deviation and is faster tha PID D I Tn y t b) B33-22 1 XP = KP
- 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 ﬁnal value • Settling time - How fast settling into some range around the ﬁnal value 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 • Reconﬁguration of software possible • Time-discrete, quantized behavior • A/D and D/A conversion requires sampling • Danger of instability through phase shift • Restricted data word length • Accumulation of rounding errors • Quantization errors • Overﬂow in calculation with wrap-around 85 Institut für Robotik und Prozessinformatik Technische Universität Braunschweig- 37/64 - Einführung in die diskrete Signalverarbeitung A/D-Wandlung D/A-Wandlung Institut für Robotik und Prozessinformatik Technische Uni- 38/64 - Abhängigkeit der Abtastperiode T
- 85. PT 15/16 Design of Software for Embedded Systems (SWES) ADJUSTINGTHE CONTROLLER • Controller adjustment by determining gain factors / coefﬁcients • 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 inﬂuence of P component, reduce inﬂuence of I component afterwards • Response oscillates slowly towards goal signal -> Increase inﬂuence of P component, reduce inﬂuence of D component afterwards • Overshooting -> Reduce inﬂuence of P component, increase inﬂuence of I component afterwards 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. 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. 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. http://osg.informatik.tu-chemnitz.de 1.1 Control System Deﬁnition (refreshment) WS15/16 Design of Software for Embedded Systems Chapter 3: Mathematical Theory of Systems and Control 90 Deﬁnition: A control system consists of subsystems and processes (or plants) assembled for the purpose of obtaining a desired output with desired performance, given a speciﬁed input. ▶ Two major goals of performance: ▶ Transient response ▶ Steady-State Error Source: [2]
- 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. 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. 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 Deﬁnition: Control system is stable if its natural response a) eventually approaches zero or b) oscillates. If the natural response of the system grows without bound and becomes much greater than forced response, the system is considered unstable. ▶ Other goals: • Finances • Robust design Source: [2]
- 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 speciﬁcations 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 speciﬁcations are met. Use the schematic to obtain a block diagram, signal-ﬂow diagram, or state-space representation. Source: [2]
- 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, deﬁne speciﬁcations for the design, e.g. transient response, steady-state accuracy 2.Functional block diagram 1.Translate qualitative description into functional subsystems 2.Deﬁne 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. 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. 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 veriﬁcation 2.Redesign if necessary 3.Test signals commonly used: Input Function Use Impulse Transient response Step Transient response Steady-state error Ramp Steady-state error Parabola Steady-state error Sinusoid Transient response Steady-state error (t) u(t) u(t)t 1 2 u(t)t2 sin !t Source: [2]
- 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. 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. 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 Deﬁnition: Differential equation is any equation which contains derivatives, either ordinary derivatives or partial. Deﬁnition: Solution to a differential equation on an interval is any function which satisﬁes the equation on this interval. ↵ < t < y(t) Deﬁnition: Order of differential equation is the larges derivative present in it. Source: [3]
- 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 Deﬁnition: Linear differential equation is any differential equation that can be written in the following form: an(t)y(n) (t) + an 1(t)y(n 1) (t) + ... + a1(t)y0 (t) + a0(t)y(t) = g(t) Note: there are no products of the function and its derivatives and neither the the function or its derivatives occur to any power other than the ﬁrst power. Source: [3]
- 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 Deﬁnition: Differential equation is time-invariant if it does not depend explicitly on time. ▶ Many techniques for solving ODEs: ▶ Linear 1st order ODEs ▶ Separable ODEs ▶ Exact ODEs ▶ Bernoulli ODEs ... N(y) dy dx = M(x) dy dt + p(t)y = g(t) M(x, y) + N(x, y) dy dx = 0 y0 + p(x)y = q(x)yn Source: [3]
- 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. Deﬁnition: The Laplace transform is deﬁned as where is a complex variable. Condition for existence:s = + j! L|f(t)| = F(s) = Z 1 0 f(t)e st dt Z 1 0 f(t)e kt dt < 1, k 2 R
- 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. 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. 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. 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. 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. 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 Deﬁnition: The inverse Laplace transform is deﬁned as where is a complex variable, is real and u(t) is a unit-step function. s = + j! L 1 |F(s)| = 1 2⇡j Z +j1 j1 F(s)est ds = f(t)u(t) Example Problem: Find inverse Laplace transform of F(s) = 1 (s + 3)2 Solution: We use frequency shift theorem and the transform of L|u(t)t| = 1 s2 L 1 | 1 (s + a)2 | = e at u(t)tSo, and f(t) = e 3t u(t)t Source: [2]
- 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 ﬁnd an ILT of a complex function? ▶ Solution: we can convert the function into a sum of simpler terms, for which we know the ILT. ▶ This method is called partial fraction expansion ▶ Assume that , where the order of is lower than that of ▶ If this is not the case, divide polynomials until this condition is fulﬁlled ▶ Three cases are possible: ▶ Roots of the denominator are real and distinct ▶ Roots of the denominator are real and repeated ▶ Roots of the denominator are complex or imaginary (not considered here) F(s) = N(s) D(s) N(s) D(s) D(s) Source: [2]
- 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 ﬁnd , we multiply this equation by (s+1) which isolates ▶ Then we let s approach -1 which eliminates last term and we get ▶ Similarly solving this for the second residue, we get ▶ The resulting function can be transformed now: F(S) = 2 (s + 1)(s + 2) = K1 s + 1 + K2 s + 2 K1 K1 2 s + 2 = K1 + (s + 1)K2 s + 2 K1 = 2 K2 = 2 f(t) = (2e t 2e 2t )u(t) Source: [2]
- 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 ﬁnd the residues for the roots of multiplicity greater than unity: ▶ For all other residues, use the method of PFE for the case 1 F(s) = N(s) D(s) = N(s) (s + p1)r(s + p2)...(s + pn) K1 (s + p1)r + K2 (s + p1)r 1 + ... + Kr s + p1 + Kr+1 s + p2 + ... + Kn s + pn Ki = 1 (i 1)! di 1 F(s) dsi 1 s! p1 , i = 1, .., r Source: [2]
- 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. 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. 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 deﬁnition of a function that algebraically relates output of the system to its input ▶ Take a general n-th order linear time-invariant ODE: ▶ Here, a, b are constants and c(t) and r(t) are output and input, respectively ▶ Assuming that all initial conditions are =0 and taking Laplace transform of both sides: ▶ The ratio is called the transfer function. It is evaluated with zero initial conditions.The output can be found by: an dn c(t) dtn + an 1 dn 1 c(t) dtn 1 + ... + a0c(t) = bm dm r(t) dtm + bm 1 dm 1 r(t) dtm 1 + ... + b0r(t) (ansn + an 1sn 1 + ... + a0)C(s) = (bmsm + bm 1sm 1 + ... + b0)R(s) C(s) R(s) = G(s) = (bmsm + bm 1sm 1 + ... + b0) ansn + an 1sn 1 + ... + a0 C(s) = G(s)R(s) Source: [2]
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 ﬁnd the transfer function of the system: Source: [2] R(s) + C(s) G1(s) G2(s) H2(s) H1(s) H3(s) G3(s) + + +
- 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. 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 ﬁnal result R(s) C(s)G3(s)G2(s)G1(s) 1 + G3(s)G2(s)(H1(s) H2(s) + H3(s)) + C(s) G3(s)G2(s) H1(s) H2(s) + H3(s) R(s) G1(s) Source: [2]
- 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. 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] Deﬁnition: The poles of a transfer function are (1) the values of the complex Laplace transform variable s that make the transfer function inﬁnite (2) roots of denominator that are also roots of the numerator N(s) D(s) Deﬁnition: 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. 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. 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. 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] Deﬁnition: is called time constant, time needed for the step response to reach 63% of its ﬁnal value 1 a Deﬁnition: Rise time is deﬁned as the time for the response to go from 0.1 to 0.9 of its ﬁnal value: Tr = 2.2 a Deﬁnition: Settling time is deﬁned as the time for the response to reach and stay within 2% of its ﬁnal value: Ts = 4 a
- 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. 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. 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. 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. 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. 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. 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. http://osg.informatik.tu-chemnitz.de 4.3 Second-Order System Characteristics Semester 141 Deﬁnition: Peak time is the time required to for the response waveform to reach the ﬁrst, or maximum, peak. Deﬁnition: Rise time is deﬁned as the time for the response to go from 0.1 to 0.9 of its ﬁnal value. Deﬁnition: Settling time is deﬁned as the time for the response to reach and stay within 2% of its ﬁnal value. Source: [2] Deﬁnition: Percent overshoot is the amount the response waveform overshoots the steady-state, expressed as a percentage of steady-state value.
- 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 Deﬁnition(BIBO): A system is stable if every bounded input produces a bounded output. Alternatively, a system is unstable if any bounded input produces an unbounded output. Deﬁnition: Control system is stable if its natural response a) eventually approaches zero or b) oscillates. If the natural response of the system grows without bound and becomes much greater than forced response, the system is considered unstable.
- 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. 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. 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 ﬁnd TF and solve!
- 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 ﬁnd TF and solve!
- 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 ﬁnd the roots ▶ Or use other techniques to analyse for stability, e.g. Routh-Hurwitz method
- 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 deﬁnition of optimality ▶ Possible goals: • Stability • Minimum overshoot • Damped noise • Minimum steady-state error • Short settling time
- 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 indeﬁnitely with period Ku Tu Control Type PI - Classic PID No Overshoot PID Ti TdKp 0.45Ku Tu/1.2 0.6Ku 0.2Ku Tu/2 Tu/2 Tu/8 Tu/3
- 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. C DESIGN OF SOFTWARE FOR EMBEDDED SYSTEMS (SWES) Dr. PeterTröger Operating Systems Group,TU Chemnitz
- 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 efﬁcient => used for embedded systems • All major operating systems are written (mostly) in C • Thin layer above assembler language • Data type semantics driven by hardware architecture • Direct memory manipulation, inline assembler supported • Few chances for compiler to check semantic correctness • Standards: C89/C90, C95, C99, C11 152
- 152. PT 15/16 Design of Software for Embedded Systems (SWES) HELLO WORLD • Implementation / source ﬁles (*.c) • Declaration / header ﬁles (*.h) • Object ﬁles (*.o on Unix, *.obj on Windows) • Static library ﬁles (*.a on Unix, *.lib on Windows) • Dynamic library ﬁles (*.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. PT 15/16 Design of Software for Embedded Systems (SWES) TECHNICAL ENVIRONMENT 154 Code / Model Compiler Object ﬁle for target Remote debugger Terminal HW debugging support SW outputs Developer PC Embedded system JTAG Serial Executed code Transfer
- 154. PT 15/16 Design of Software for Embedded Systems (SWES) C PREPROCESSOR • C preprocessor • Simple text replacement for „#deﬁne“ and „#include“ • C Header Files • Separate declaration and implementation • „#include“ preprocessor directive includes one ﬁle in another ﬁle • Easiest way to include declaration into implementation ﬁle • Embedded world: Nice to separate hardware speciﬁcs • Several predeﬁned 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. 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. PT 15/16 Design of Software for Embedded Systems (SWES) C STATEMENTS • Statement syntax has inﬂuenced C++, Java, C# and many others • if(condition) statement else statement • for(init;condition;step) statement • while(condition) statement • do statement while(condition); • switch(condition) { case-block } • Blocks • Expressions • return, break, continue 157
- 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 efﬁcient on the hardware • Qualiﬁers: long (at least 32 bit), short (at least 16 bit) • sizeof(char) <=sizeof(short) <= sizeof(int) <= sizeof(long) • ﬂoat - Floating point number with single precision • double - Floating point number with double precision • Support for enumerations • signed, unsigned -Type qualiﬁers 158
- 158. [Wikipedia]
- 159. PT 15/16 Design of Software for Embedded Systems (SWES) 64 BIT DATA MODELS 160 [Wikipedia]
- 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. 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 ﬂow of the program (e.g. by hardware) 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. 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. 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. PT 15/16 Design of Software for Embedded Systems (SWES) ARRAYS AND POINTERS • Value of an array variable is the address of the ﬁrst element • Every array indexing operation can be expressed as pointer operation • Sometimes faster • Array and pointer are not the same • Arrays are not variables, not allowed on left side of an expression • Arrays as function argument result in address of the ﬁrst element • Allows to hand over only parts of the array to some function 166 *(array_var+3) pa = &a[0]; equals pa = a; a[i] equals *(a+i); func(&a[2]);
- 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. PT 15/16 Design of Software for Embedded Systems (SWES) ARRAYS AND POINTERS • Pointers can be added, subtracted and compared • Pointer arithmetics - very efﬁcient and dangerous tool • Inc / dec steps in accordance to the data type being pointed to • All pointers can be converted to „void*“ and reverse • No runtime checks for memory access through array index or pointer • Compiler converts it to native code, no underlying runtime • Illegal access may be defeated by operating system • Unintended access to process data possible (stack-based buffer overﬂow attack on return address) • Pointer can reference functions (start address in code segment) 168 (* compare) ( ”hello”, ”world” );
- 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 Overﬂow 0x0000...
- 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 ﬁxed-size index variable 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. PT 15/16 Design of Software for Embedded Systems (SWES) DEPENDABLE C CODE • Low-level approach makes C code fast and memory-efﬁcient • But also only minimal protection from programmer mistakes • Different ways to achieve dependable C code • Fault avoidance - Prevent bugs from being introduced • Coding conventions or C code generation • Depends on understanding of typical fault causes • Fault removal - Find bugs before going into production • Testing, whole program analysis • Fault tolerance and fault prediction 172
- 172. PT 15/16 Design of Software for Embedded Systems (SWES) DEPENDABLE C CODE • Problematic properties of the C language • Intentionally implementation-deﬁned behavior • Examples: Expression evaluation order, numerical types, register type • Chance for compiler optimizations • Intentionally non-portable semantics • Example: LOCALE in character / string handling • Intentionally undeﬁned behavior • Example: Reaction on run-time problems, such as non-initialized variables being used 173
- 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. 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. PT 15/16 Design of Software for Embedded Systems (SWES) IOCCC.ORG 176 http://ioccc.org/years-spoiler.html
- 176. PT 15/16 Design of Software for Embedded Systems (SWES) C STYLE GUIDES 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. PT 15/16 Design of Software for Embedded Systems (SWES) FUNCTION MACROS • Code considers platform speciﬁcs on memory copy operation • memcpy() function may be implemented by a preprocessor macro • Compiler behavior undeﬁned • Either re-formulate code or forbid function macros 179 [https://www.securecoding.cert.org/]
- 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. 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. 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 ﬁrst result • Variables are considered the same even though they are not • ‚Heisenbug‘ 182 [https://www.securecoding.cert.org/]
- 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 ﬁles should have comment block • Only readable part of library code • Version information, usage license, authors, support contact 183 /******************************************************************* * Product: . . * Version: . . * Updated: November 26 2015 * Copyright (C) 2015-2015 Brillant student <brilliant@student.org> * <licensing terms> (if any) *******************************************************************/
- 183. PT 15/16 Design of Software for Embedded Systems (SWES) COMMENTING 184 [freescale.com]
- 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 deﬁnition may not be portable • Semantical, not syntactical issue 185 // Define struct overlay typedef struct { unsigned int count; // Offset 0x00 unsigned int max; // Offset 0x02 unsigned int _reserved; // Offset 0x04 unsigned int flags; // Offset 0x06 } Counter; // Create pointer to chip base address Counter volatile * const pCounter = 0x10000000; // Next line is equal to // *((unsigned int *)0x10000002) = 5000; pCounter->max = 5000; pCounter->flags |= GO; ... // Poll timer state if (pCounter->flags &= DONE) { ... }
- 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 efﬁciency • Trade-off between optimal portability and optimal performance 186 [freescale.com]
- 186. PT 15/16 Design of Software for Embedded Systems (SWES) DATATYPES • Raw C data types allows compiler to choose most efﬁcient storage • Most coding conventions recommend to not use them • Projects deﬁne their own data type abstractions • <stdint.h> for C99 provides portable data types • int8_t: signed 8-bit uint8_t: unsigned 8-bit • 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. 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. 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 deﬁne constant objects instead 189 const int x=1; void f(int& x); // ... const int i; f(i); int const *px; int * const px;
- 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. PT 15/16 Design of Software for Embedded Systems (SWES) MISRA-C RULES • Categories of problems being tackled • Common programming errors in C • Underspeciﬁed language aspects, interpreted by compiler vendors • Common misconceptions of C language properties • Compiler errors and runtime errors • Targeting human developers • Some problems never occur in code generators • Rule may even impact performance (http://bit.ly/1pGpHpo) • In MISRA-C 2012, 27 undecidable rules • No possible to evaluate rule in each and every case 191
- 191. PT 15/16 Design of Software for Embedded Systems (SWES) MISRA-C:TOOL SUPPORT 192 [electronicdesign.com]
- 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 ﬂoating points • No pointer arithmetic, no octals • No recursion • Memory shall only be freed if allocated by the application itself • Use of typedef’s (with size and signedness) instead of basic types 193 /* ... pages later... foo(); /* ... */ ... pages later... */ void fn ( void ) { int32_t a; free(&a); } line_a |= 256; /* sets bit nr. 8 */ line_b |= 128; /* sets bit nr. 7 */ line_c |= 064; /* wrongly sets bits 2,4 and 5 */
- 193. PT 15/16 Design of Software for Embedded Systems (SWES) MISRA-CVARIABLES • All variables shall have a deﬁned value before being used • No unused variables • No non-volatile variables with only one use • Variables may be undeﬁned (U), deﬁned (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. 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-speciﬁc language extensions“ • Tries to ensure portable C Code • No need when C code is just an intermediate language • „Wrap assembler code in C functions“ • Avoids erroneous utilization of macros in manual coding • Destroys performance advantage from inline assembler • „No pointer arithmetic“ • Code generator can be expected to work correctly here • Some rules can be enforced on model level instead (e.g. no recursion) 195
- 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 efﬁcient, and even used in OS kernels • Dynamic memory allocation is not allowed, waste of resources • No stdio.h allowed, but may be useful 196 http://www.knosof.co.uk/misracom.html
- 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“

Keine öffentlichen Clipboards für diese Folie gefunden

Sie haben diese Folie bereits ins Clipboard „“ geclippt.

Clipboard erstellen

Als Erste(r) kommentieren