1、_SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising theref
2、rom, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions. Copyright 2008 SAE International All rights reserved. No part of this publication ma
3、y be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: 724-776-4970 (outside USA)
4、Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.orgJ2640 OCT2008 SURFACEVEHICLERECOMMENDEDPRACTICEIssued 2006-04Revised 2008-10 Superseding J2640 APR2006 (R) General Automotive Embedded Software Design Requirements RATIONALEChanges were made based on the feedback from
5、the previously balloted document. Changes include consistent terminology usage and spelling mistakes in the following section; 3. Definitions 5.1.2 Use of Interrupts Caused by Module Input Signals (1-2) 5.1.3 Bounding Interrupt Overhead (1-3) 5.1.4 Use of Nested Interrupts (1-4) 5.2.1 Worst-Case CPU
6、 Load Measurement (2-1) 5.2.4 Use of Software Wait Loops (2-4) 5.3.1 Initialization of All Control Registers (3-1)5.3.2 Refreshing Control Registers (3-2) 5.3.3 Clock Prescaler and Pll (3-3) 5.5.2 Unused Memory (5-2) 5.5.4.4 Data Integrity Recovery (5-6) 5.5.4.6 Non-Volatile Memory Initialization (5
7、-8) Appendix A Discussion on System Design Interactions FOREWORDNOTE: This document represents input from software experts in the automotive embedded software industry. Participants are from the OEMs, the automotive electronic module supplier base, related software suppliers, and consultants to the
8、industry. TABLE OF CONTENTS 1. SCOPE 32. REFERENCES 33. DEFINITIONS . 33.1 Automotive Embedded Software 33.2 Corner Frequency . 33.3 Customer. 33.4 Embedded Software Anomaly 43.5 Embedded Software Robustness . 43.6 Hard Real-Time. 43.7 LOS (Limited Operating Strategy). 43.8 Multi-Threading (Multi-Ta
9、sking) 4Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2640 Revised OCT2008 - 2 -3.9 Non-Preemptive System . 53.10 NVM (Non-Volatile Memory). 53.11 Overlapping Interrupts 53.12 Preemptive Syste
10、m. 53.13 Resource Sharing . 53.14 Sleep Mode . 53.15 Soft Real-Time 53.16 Stop-Band Frequency . 63.17 Supplier . 63.18 Watchdog 64. OVERVIEW. 64.1 Elements of a Requirement 64.2 Requirement Heuristics. 65. FUNDAMENTAL REQUIREMENTS. 65.1 Interrupt Requirements . 65.1.1 Use of Interrupts (1-1). 65.1.2
11、 Use of Interrupts Caused by Module Input Signals (1-2) 75.1.3 Bounding Interrupt Overhead (1-3). 85.1.4 Use of Nested Interrupts (1-4) 85.2 Timing Consistency Requirements . 95.2.1 Worst-Case CPU Load Measurement (2-1) . 95.2.2 Worst-Case CPU Load Margin (2-2). 95.2.3 Software Measuring Timing (2-3
12、) . 105.2.4 Use of Software Wait Loops (2-4). 105.3 Microcontroller Consistency Requirements 115.3.1 Initialization of All Control Registers (3-1). 115.3.2 Refreshing Control Registers (3-2) . 125.3.3 Clock Prescaler and PLL (3-3) 125.4 Watchdog Requirements 135.4.1 Use of a Watchdog Timer (4-1). 13
13、5.4.2 Servicing the Watchdog Timer (4-2) . 135.5 Memory Requirements 145.5.1 Run-Time Data Integrity Checking (5-1). 145.5.2 Unused Memory (5-2) . 145.5.3 Dynamic Memory Allocation (5-3). 145.5.4 Non-Volatile Memory Requirements. 155.6 Microcontroller Selection Requirements. 185.6.1 Use of a Custom
14、Microcontroller (6-1) 195.6.2 Determining Memory Size (6-2) 196. HARDWARE INTERFACE REQUIREMENTS (NEVER TRUST A RAW INPUT SIGNAL) . 206.1 Discussion. 206.1.1 Control Theory 206.1.2 Noise Sources. 216.1.3 Debounce Algorithms 216.2 Digital Input Interfacing Requirements 226.2.1 Regular, Periodic Sampl
15、ing (7-1) 226.2.2 Low Pass Input Filter (7-2) 226.2.3 Digital Input Debounce (7-3). 246.3 Analog Input Interfacing Requirements 246.3.1 Filter Matching - Just To Get One Valid Sample 246.3.2 Software Versus Hardware Ratiometric Conversions - Just To Get One Valid Sample 256.3.3 Stabilizing A Discret
16、e Analog Input. 266.3.4 Measuring A Steady-State Continuous Analog Signal . 27Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2640 Revised OCT2008 - 3 -7. UPCOMING TOPICS 278. NOTES 288.1 Margin
17、al Indicia. 28APPENDIX A DISCUSSION ON SYSTEM DESIGN INTERACTIONS.29A.1 DEBOUNCING AND POWER SUPPLY . 29A.2 DEBOUNCING AND SLEEP/AWAKE 29A.3 SYSTEM VOLTAGE . 29A.4 DEBOUNCING AND SYSTEM VOLTAGE . 29A.5 DEBOUNCE, VOLTAGE MONITORING, KEY-OFF LOAD AND SLEEP/AWAKE 30A.6 SLEEP/AWAKE AND NVM MODIFICATIONS
18、 . 30A.7 VOLTAGE DROPOUT 30A.8 SUGGESTIONS FOR IMPROVING SYSTEM RELIABILITY. 30APPENDIX B SUGGESTED RELATED MATERIALS 31B.1 BOOK RESOURCES 31B.1.1 Software Standards 31B.1.2 Software Reliability 311. SCOPE The scope of this Recommended Practice encompasses the following objectives: Concentrate on ge
19、neral best practices for vehicular embedded software design. Establish programming language-independent best practices. Establish hardware/software interface best practices. Establish multi-threaded system best practices. Provide verification criteria to evaluate product compliance with this best pr
20、actice. 2. REFERENCES There are no referenced publications specified herein. 3. DEFINITIONS 3.1 Automotive Embedded Software A set of instructions that controls special purpose hardware residing in a vehicle. 3.2 Corner Frequency The corner frequency is defined as the frequency at which the output i
21、s attenuated by 3 decibels (1/2 the power) of the input signal for a single pole filter. Half the power is 1/Sqrt(2) or 0.707 gain. 3.3 Customer The company that requested the embedded software. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networ
22、king permitted without license from IHS-,-,-SAE J2640 Revised OCT2008 - 4 -3.4 Embedded Software Anomaly Any unexpected behavior exhibited by the software regardless of whether the anomaly is induced by external module conditions (for example an electrical transient or a gamma ray that flips a bit i
23、n a control register) or internally caused by ahardware anomaly (for example, the watchdog timer fails to initialize) or internally caused by a software problem (for example, a stack overflow is not detected). 3.5 Embedded Software Robustness A measure of the predictability of softwares response to:
24、 Unusual and unexpected inputs and loads (CPU, interrupts, network.) Unanticipated events Hardware and software defects Hardware failures Errors introduced during system maintenance. 3.6 Hard Real-Time A real-time system can be classified as either hard or soft. The distinction, however, is somewhat
25、 fuzzy. As illustrated in Figure 1 - Real-Time Spectrum, the meaning of real-time spans a spectrum. At one end of the spectrum is non-real-time, where there are no important deadlines (meaning all deadlines can be missed). The other end is hard real-time, where no deadlines can be missed. Every appl
26、ication falls somewhere between the two endpoints. FIGURE 1 - REAL-TIME SPECTRUM A hard real-time system is one in which one or more activities must never miss a deadline or timing constraint, otherwise the system fails. Failure includes damage to the equipment, major loss in revenues, or even injur
27、y or death. 3.7 LOS (Limited Operating Strategy) Strategy for providing limited functionality under failure conditions. 3.8 Multi-Threading (Multi-Tasking) Method whereby multiple tasks (or processes/threads) run on a single CPU. Only one tasks/process/threads is “running” at any one time. A “schedu
28、ler” switches between threads in order to simulate simultaneous thread execution. There are two basic types of multi-threading: cooperative and preemptive. Cooperative: the threads voluntarily give up control at thread defined points. Preemptive: control is taken from a thread at any time. NOTE: The
29、 difference between task, processes and threads is not pertinent to this discussion. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2640 Revised OCT2008 - 5 -3.9 Non-Preemptive System A system
30、where none of the tasks can preempt the execution of the current task and take control of the processor. A non-preemptive system doesnt use interrupts and relies entirely on polling. Any system that uses interrupts is preemptive system. 3.10 NVM (Non-Volatile Memory) Programmatically alterable memor
31、y used to store data values when power is removed. 3.11 Overlapping Interrupts An overlapping interrupt occurs when an interrupt is asserted prior to completion of processing of the previous assertion of the same interrupt. An overlapping interrupt can be caused by any of the following items: Proces
32、sing of the interrupt takes longer than the minimum possible time between interrupts Processing of higher-priority interrupts causes the first interrupt assertion to experience latency greater than the minimum possible time between interrupts. Many advanced 32-bit CPU architectures have multiple lev
33、els of interrupts. Critical sections of software inhibit interrupts such that an interrupt can be asserted twice between the beginning of the critical section and the completion of processing the first assertion. This includes any latency issues caused by higher-priority interrupts. Poor filtering o
34、f the signal causing spurious interrupts (ringing, noise.) A combination of any or all the above issues. Overlapping interrupts are a system issue and require good system design practices to ensure that they can never occur. Since interrupts are by nature asynchronous, they cannot be anticipated and
35、 worst-case analysis is usually required. 3.12 Preemptive System A system where one or more tasks or interrupts can preempt the current task and take control of the processor. A preemptive system uses a preemptive operating system with multiple tasks or interrupts or both. A simple round-robin sched
36、uler with interrupts is a preemptive system. 3.13 Resource Sharing A resource is defined as any component within a computer based system that is used by the application to accomplish a task. Examples include the processor, memory, I/O, etc. Resources may be dedicated or shared. For example, the memo
37、ry in which the application is running is typically dedicated, while global memory is shared. As soon as any resource is shared, the application must provide a means to manage this sharing. Resource sharing is the management of resources that are shared between different areas of the application to
38、ensure data consistency, system integrity, and resource availability. Typically, the Operating System or Kernel has resource sharing management services, but it is left to the developer to determine when to use these services. In embedded systems, typical shared resources that must be managed includ
39、e Non-Volatile RAM or EEPROM, communications channels (SAE J1850, CAN, LIN), global variables used by interrupts or multiple tasks, and I/O. Often overlooked resources are data items shared between tasks that take multiple memory cycles to access (bit-fields, large memory blocks). 3.14 Sleep Mode A
40、special module-operating mode that uses a low quiescent current but is still able to respond to a limited set of inputs. Usually this only occurs when the ignition is off. 3.15 Soft Real-Time A soft real-time system is one that has timing requirements, but occasionally missing them has negligible ef
41、fects, as application requirements as a whole continue to be met. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2640 Revised OCT2008 - 6 -3.16 Stop-Band Frequency The frequency above which the
42、 attenuation of the signal could exceed a specified value. Typically, this is specified to guarantee that the signal does not produce a response. For example, TTLs would use an attenuation of 0.9 for a 5 volt signal, this attenuation would guarantee the filter response in the Stop-Band frequency to
43、be 0-0.5V. 3.17 Supplier The company that provided the embedded software to the Customer. 3.18 Watchdog A watchdog is a device that is used to protect a system from lockup causing the system to stop responding. Software errors are one of the major contributors to lockup, but other issues can also ca
44、use it. Normally the system must periodically send information to the watchdog (pet the dog) to keep it from rebooting/restarting the microcontroller or system. 4. OVERVIEW 4.1 Elements of a Requirement Each requirement is composed of the following elements (some of which are optional): Requirement
45、Title (m-n) where m-n is the traceable requirement number. o “m” is the requirement category 1 is Interrupts 2 is Timing Consistency 3 is Data Consistency 4 is Watchdog 5 is Memory REQUIREMENT Describes the requirement. CATEGORY Type of requirements JUSTIFICATION Supports the reasons why the require
46、ment is needed. EXCEPTIONS Lists any acceptable exceptions to the requirement. REVIEW QUESTIONS These are typical questions that will be asked at the design review. 4.2 Requirement Heuristics Embedded software is not robust when the software design and implementation have not addressed all condition
47、s that might introduce an anomaly. The requirements in this document will reduce the incidence of these anomalies. 5. FUNDAMENTAL REQUIREMENTS 5.1 Interrupt Requirements 5.1.1 Use of Interrupts (1-1) 5.1.1.1 Requirement Use of interrupts must be limited to the absolute minimal set needed to perform
48、the required task(s). 5.1.1.2 Justification Interrupts introduce preemptive resource sharing issues. The history of module development has demonstrated that preemptive resource sharing anomalies are a leading cause of recalls, product introduction delays, and slow product update turnarounds. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2640 Revised OCT2008 - 7 -5.1.1.3 Review Questi
