>>> Confiana em tempo real >>> Aprendizados em - PowerPoint PPT Presentation

>>> Confiança em tempo real >>> Aprendizados em software embarcado crítico Name: Ricardo Bedin França ∗ Datum: April 25, 2017 ∗ ricardo.franca@embraer.com.br [~]$ _ [1/28]

>>> Table of Contents 1. Introduction 2. How we develop aircraft control SW 3. Our metric: Worst-case Execution Time (WCET) 4. Dirty coding tricks 5. Getting to know your compiler [~]$ _ [2/28]

Section 1 Introduction [1. Introduction]$ _ [3/28]

>>> About the presenter 2006-08 Formal methods for embedded SW (UFSC, IRIT) [1. Introduction]$ _ [3/28]

>>> About the presenter 2006-08 Formal methods for embedded SW (UFSC, IRIT) 2009-12 Optimize flight control SW (IRIT, Airbus) [1. Introduction]$ _ [3/28]

>>> About the presenter 2006-08 Formal methods for embedded SW (UFSC, IRIT) 2009-12 Optimize flight control SW (IRIT, Airbus) 2012- Develop flight control SW (Embraer) [1. Introduction]$ _ [3/28]

>>> About the presenter 2006-08 Formal methods for embedded SW (UFSC, IRIT) 2009-12 Optimize flight control SW (IRIT, Airbus) 2012- Develop flight control SW (Embraer) * Bottom line: Living in Plato’s cave [1. Introduction]$ _ [3/28]

>>> Lecture objectives * Summarize performance-related challenges in airborne SW * Devise possible solutions to these challenges * (Hopefully) Employ new tricks in your own software [1. Introduction]$ _ [4/28]

Section 2 How we develop aircraft control SW [2. How we develop aircraft control SW]$ _ [5/28]

>>> One-slide summary Mobile, cloud Embedded, soft RT DO-178C, level A [2. How we develop aircraft control SW]$ _ [5/28]

>>> What really changes in airborne SW? * A bug may mean a disaster * Aircraft accidents are especially infamous [2. How we develop aircraft control SW]$ _ [6/28]

>>> What really changes in airborne SW? * A bug may mean a disaster * Aircraft accidents are especially infamous * Strict timing deadlines * Must be efficient and predictable [2. How we develop aircraft control SW]$ _ [6/28]

>>> What really changes in airborne SW? * A bug may mean a disaster * Aircraft accidents are especially infamous * Strict timing deadlines * Must be efficient and predictable * Long, but small, production runs * 100’s / 1000’s units flying for decades * HW makers care little about us [2. How we develop aircraft control SW]$ _ [6/28]

>>> What about that DO-178C thing? * A document that guides the life cycle of airborne SW * It strangles guides us according to product criticality * Aircraft certification authorities require us to follow it [2. How we develop aircraft control SW]$ _ [7/28]

>>> Scope of this lecture * Bit-shaver point of view * Process is a swearword! * Focus on good coding and smart verification * However, the entire development is interdependent [2. How we develop aircraft control SW]$ _ [8/28]

>>> Scope of this lecture * Emphasis to control software * No direct interaction with users * Little parallelism * May seem boring but commands very critical equipment   elevCmd [ k ] ailCmd [ k ]     rudCmd [ k ] = F ( α [ k ] , β [ k ] , γ [ k ] , elevCmd [ k − 1 ] , ... )   stallWarn [ k ]     . . . [2. How we develop aircraft control SW]$ _ [9/28]

Section 3 Our metric: Worst-case Execution Time (WCET) [3. Our metric: Worst-case Execution Time (WCET)]$ _ [10/28]

>>> Our metric: Worst-case Execution Time (WCET) What is WCET? * Highest possible execution time for a program Why is it important? * Critical SW shall never miss a deadline * You don’t want a blue screen in a crosswind landing! [3. Our metric: Worst-case Execution Time (WCET)]$ _ [10/28]

>>> How we compute the WCET * It is essentially NP-hard * Ideally, we want it to be sound and tight Static analysis tools Measurement-based * Simpler but unsound * Sophisticated and sound * Requires lots of tests * Tests made by tool maker * Less coupled to HW * Quick computation * ‘‘Is this representative?’’ * Very coupled to HW [3. Our metric: Worst-case Execution Time (WCET)]$ _ [11/28]

>>> How we compute the WCET Which method is better? * Ferocious battles between rival researchers * Personal experience: it depends on... * Which HW you use * How critical is your SW * How much you can tinker with your HW * No proven solution for multi-cores! * Both methods have common points * More than many researchers would admit... [3. Our metric: Worst-case Execution Time (WCET)]$ _ [12/28]

>>> How we compute the WCET Common tips and tricks * Both methods work easily for simple hardware * !(pipelines || caches || branch prediction) * Avoid messy caches (random, round-robin, unified) * Bound resource contention sources * Bound recursion and loops * In Plato’s cave, we have almost no loops [3. Our metric: Worst-case Execution Time (WCET)]$ _ [13/28]

>>> Cache policy vs. timing behavior * Unified caches (MPC5307, MPC5554) are disturbing * Making them instruction-only helped predictability [3. Our metric: Worst-case Execution Time (WCET)]$ _ [14/28]

>>> Cache policy vs. timing behavior So what? My app runs at someone else’s device. * OK, you really cannot fine-tune hardware * Neither you need to prove your timing upper bound * And you can blame their obsolete phones! * At least, bound your loops... * And let’s go to code optimizations! [3. Our metric: Worst-case Execution Time (WCET)]$ _ [15/28]

Section 4 Dirty coding tricks [4. Dirty coding tricks]$ _ [16/28]

>>> Control SW development chain * Design models (Simulink or SCADE) * Automatic code generation * Sometimes a blessing, sometimes a curse * Code (C, Ada) what can’t/shouldn’t be done in models * Sequential, low-level, specially optimized [4. Dirty coding tricks]$ _ [16/28]

>>> Saving memory: Sliding debounce What is a sliding debounce? * ‘‘At least 3 C_TRUE in the last 5 time instants’’ * ‘‘Memories’’ must be static or global * Naive coding: 5 bool + 1 int per instance [4. Dirty coding tricks]$ _ [17/28]

>>> Saving memory: Sliding debounce Autocode: typedef struct { ‘‘Imported’’ from C: /*---initialization---*/ typedef struct { unsigned char init; unsigned int counter: 4; /*------memories------*/ unsigned int my_bools: 5; unsigned char fby_SD_5[5]; unsigned int padding: 23; unsigned int array_manager; } outC_SD_5; unsigned int counter; } outC_SD_5; [4. Dirty coding tricks]$ _ [18/28]

>>> Saving memory: Sliding debounce Why polluting the code with bitfields? * Microcontrollers have fast and scarce internal RAM * Control SW may have lots of sliding debounces! * SD_250 appeared in the very end of a project * This alone could ruin the program! * For devices with slow memory, this saves CPU * Also useful for data exchange (buses, shared memory) * Communication up to 32x faster [4. Dirty coding tricks]$ _ [19/28]

>>> Saving CPU: macros Even stackoverflow.com tells me not to!! This must be evil. * ioccc.org rewards the best preprocessor abuse! * Small and frequent functions are expensive * Function inline is not very controllable * Code generator and macros: no need to worry * Human and macros: you review and test, don’t you? [4. Dirty coding tricks]$ _ [20/28]

>>> Saving CPU: macros ACG expectations #ifndef FloatMin_BASIC extern float FloatMin_BASIC( What we do in SCADE float Value1, float Value2); #endif What we code #define FloatMin_BASIC(\ Value1, Value2)\ ((Value1 < Value2) ?\ Value1 : Value2) [4. Dirty coding tricks]$ _ [21/28]

>>> Saving CPU: not-so-defensive programming * In critical SW, we test with huge code coverage * Not easy to have 100% reusable code * Lots of bureaucracy when officially reusing * More often, we reuse ideas * ‘‘I am defending our program from what?’’ [4. Dirty coding tricks]$ _ [22/28]

>>> Case study: a simple filter * Its standard equation has a division * Should it be protected? [4. Dirty coding tricks]$ _ [23/28]

>>> Case study: a simple filter * Its standard equation has a division * Should it be protected? * How can I insert a zero time constant? * Usually, a huge bug or a HW glitch * What protection does the saturation offer? * Sometimes, it simply propagates improper data [4. Dirty coding tricks]$ _ [23/28]

>>> Case study: a simple filter * Benefits depend on system architecture * Take care with divisions in safety-critical! * In this specific case: is it necessary? * Normally, filters are tuned offline * The time constant is then constant! * We can use its inverse * No polemics, faster code [4. Dirty coding tricks]$ _ [24/28]

>>> Fun with pointers * What about null pointer checking? * Only for ‘‘slightly’’ critical stuff * When ultra-critical, static allocation void iAmCritical( float *mostImportantSignal) { if (mostImportantSignal == 0) { trapAndDespair(); /* no decent recovery */ } else { work(); } } [4. Dirty coding tricks]$ _ [25/28]

Section 5 Getting to know your compiler [5. Getting to know your compiler]$ _ [26/28]