1、 g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58applications Part 3: OSEK/VDX Operating System (OS)ICS 43.040.15Road vehicles Open interface for em
2、bedded automotive BRITISH STANDARDBS ISO 17356-3:2005BS ISO 17356-3:2005This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 January 2006 BSI 31 January 2006ISBN 0 580 47286 8The British Standards which implement international publications refe
3、rred to in this document may be found in the BSI Catalogue under the section entitled “International Standards Correspondence Index”, or by using the “Search” facility of the BSI Electronic Catalogue or of British Standards Online.This publication does not purport to include all the necessary provis
4、ions of a contract. Users are responsible for its correct application. Compliance with a British Standard does not of itself confer immunity from legal obligations.Summary of pagesThis document comprises a front cover, an inside front cover, the ISO title page, pages ii to x, pages 1 to 61 and a bac
5、k cover.The BSI copyright notice displayed in this document indicates when the document was last issued.Amendments issued since publicationAmd. No. Date CommentsA list of organizations represented on this committee can be obtained on request to its secretary.Cross-referencesenquiries on the interpre
6、tation, or proposals for change, and keep UK interests informed; monitor related international and European developments and promulgate them in the UK.National forewordThis British Standard reproduces verbatim ISO 17356-3:2005 and implements it as the UK national standard.The UK participation in its
7、 preparation was entrusted to Technical Committee AUE/16, Electrical and electronic equipment, which has the responsibility to: aid enquirers to understand the text; present to the responsible international/European committee any Reference numberISO 17356-3:2005(E)INTERNATIONAL STANDARD ISO17356-3Fi
8、rst edition2005-11-01Road vehicles Open interface for embedded automotive applications Part 3: OSEK/VDX Operating System (OS) Vhicules routiers Interface ouverte pour applications automobiles embarques Partie 3: Systme dexploitation OSEK/VDX BS ISO 17356-3:2005ii iiiContents Page Foreword. v Introdu
9、ction . vi 1 Scope 1 2 Normative references 1 3 Architecture of the operating system “OS” 1 3.1 Processing levels.1 3.2 Conformance classes3 3.3 Relationship between OS and OSEKtime OS .4 4 Task management5 4.1 Task concept5 4.2 Task state model5 4.3 Activating a task 8 4.4 Task switching mechanism
10、8 4.5 Task priority .8 4.6 Scheduling policy 9 4.7 Termination of tasks12 5 Application modes.12 5.1 General12 5.2 Scope of application modes .12 5.3 Start-up performance 13 5.4 Support for application modes.13 6 Interrupt processing13 6.1 General13 7 Event mechanism 14 8 Resource management .16 8.1
11、 General16 8.2 Behaviour during access to occupied resources 16 8.3 Restrictions when using resources.17 8.4 Scheduler as a resource .17 8.5 General problems with synchronization mechanisms 17 8.6 Priority Ceiling Protocol18 8.7 Priority Ceiling Protocol with extensions for interrupt levels.19 8.8 I
12、nternal resources21 9 Alarms.22 9.1 General22 9.2 Counters .22 9.3 Alarm management22 9.4 Alarm-callback routines 23 10 Messages24 11 Error handling, tracing and debugging .24 11.1 Hook routines.24 11.2 Error handling 25 11.3 System start-up26 11.4 System shutdown 28 11.5 Debugging 28 12 Description
13、 of system services29 BS ISO 17356-3:2005iv 12.1 Definition of system objects 29 12.2 Conventions. 29 13 Specification of OS services 31 13.1 Basics. 31 13.2 Common data types 32 13.3 Task management. 33 13.4 Interrupt handling . 38 13.5 Resource management. 41 13.6 Event control . 43 13.7 Alarms 46
14、 13.8 OS execution control 50 13.9 Hook routines 51 14 Implementation- and application-specific topics. 54 14.1 General . 54 14.2 Implementation hints 54 14.3 Application design hints 56 14.4 Implementation-specific tools . 60 BS ISO 17356-3:2005vForeword ISO (the International Organization for Stan
15、dardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right
16、 to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International S
17、tandards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an
18、International Standard requires approval by at least 75 % of the member bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO 17
19、356-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment. ISO 17356 consists of the following parts, under the general title Road vehicles Open interface for embedded automotive applications: Part 1: General structure and terms, defin
20、itions and abbreviations terms Part 2: OSEK/VDX specifications for binding OS, COM and NM Part 3: OSEK/VDX Operating System (OS) Part 4: OSEK/VDX Communication (COM) Part 5: OSEK/VDX Network Management (NM) Part 6: OSEK/VDX Implementation Language (OIL) BS ISO 17356-3:2005vi Introduction 0.1 System
21、philosophy Automotive applications are characterized by stringent real-time requirements. Therefore, the operating system (OS) offers the necessary functionality to support event-driven control systems. The specified OS services constitute a basis to enable the integration of software modules made b
22、y various manufacturers. To be able to react to the specific features of the individual control units as determined by their performance and the requirements of a minimum consumption of resources, the prime focus was not to achieve 100 % compatibility between the application modules, but their direc
23、t portability. As the OS is intended for use in any type of control units, it supports time-critical applications on a wide range of hardware. A high degree of modularity and ability for flexible configuration are prerequisites to making the OS suitable for low-end microprocessors and complex contro
24、l units alike. These requirements have been supported by definition of “conformance classes” (see 3.2) and a certain capability for application specific adaptations. For time-critical applications, dynamic generation of system objects was left out. Instead, generation of system objects was assigned
25、to the system generation phase. Error inquiries within the operating system are obviated to a large extent, so as not to affect the speed of the overall system unnecessarily. On the other hand, a system version with extended error inquiries has been defined. It is intended for the test phase and for
26、 less time-critical applications. Even at that stage, defined uniform system appearance is ensured. 0.1.1 Standardized interfaces The interface between the application software and the OS is defined by system services. The interface is identical for all implementations of the OS on various processor
27、 families. System services are specified in an ISO/ANSI-C-like syntax, however the implementation language of the system services is not specified. 0.1.2 Scalability Different conformance classes, various scheduling mechanisms and the configuration features make the OS feasible for a broad spectrum
28、of applications and hardware. The OS is designed to require only a minimum of hardware resources (RAM, ROM, CPU time) and therefore runs even on 8-bit microcontrollers. 0.1.3 Error checking The OS offers two levels of error checking, extended status for development phase and standard status for prod
29、uction phase. The extended status allows for enhanced plausibility checks on calling OS services. Due to the additional error checking, it requires more execution time and memory space than the standard version. However, many errors can be found in a test phase. After all errors have been eliminated
30、, the system can be recompiled with the standard version. BS ISO 17356-3:2005vii0.1.4 Portability of application software One of the goals of ISO 17356 is to support the portability and re-usability of application software. Therefore, the interface between the application software and the OS is defi
31、ned by standardized system services with well-defined functionality. Use of standardized system services reduces the effort to maintain and to port application software and development cost. Portability means the ability to transfer an application software module from one ECU to another without bigg
32、er changes inside the application. The standardized interface (service calls, type definitions and constants) to the operating system supports the portability on source code level. Exchange of object code is not addressed by ISO 17356. The application software lies on the operating system and in par
33、allel on an application-specific Input/Output System interface which is not standardized in ISO 17356. The application software module can have several interfaces. There are interfaces to the OS for real-time control and resource management, but also interfaces to other software modules to represent
34、 a complete functionality in a system, and at least to the hardware, if the application works directly with microcontroller modules. Figure 1 Software interfaces inside ECU1)During the process to port application software from one ECU to another, it is necessary to consider characteristics of the so
35、ftware development process, the development environment and the hardware architecture of the ECU, for example: software development guidelines; file management system; data allocation and stack usage of the compiler; memory architecture of the ECU; timing behaviour of the ECU; different microcontrol
36、ler specific interfaces e.g. ports, A/D converter, serial communication and watchdog timer; and placement of the API calls. 1) OSEK OS allows direct interfacing between application and the hardware. BS ISO 17356-3:2005viii This means that the specifications are not enough to describe an implementati
37、on completely. The implementation supplies specific documentation. 0.1.5 Support of portability The certification process ensures the conformance of different implementations to the specification. Clause 14 of this International Standard collects implementation specific details which should be regar
38、ded to increase portability of an application between various implementations. Herein, only the OS interface to the application is considered. 0.1.6 Special support for automotive requirements Specific requirements for the OS arise in the application context of software development for automotive co
39、ntrol units. The following features address requirements such as reliability, real-time capability and cost sensitivity: The OS is configured and scaled statically. The user statically specifies the number of tasks, resources and services required. The specification of the OS supports implementation
40、s capable of running on ROM, i.e. the code could be executed from Read-Only-Memory. The OS supports portability of application tasks. The specification of the OS provides a predictable and documented behaviour to enable OS implementations, which meet automotive real-time requirements. The specificat
41、ion of the OS allows the implementation of predictable performance parameters. 0.2 Purpose of this document The following description is to be regarded as a generic description which is mandatory for any implementation of the OS. This concerns the general description of strategy and functionality, t
42、he interface of the calls, the meaning and declaration of the parameters and the possible error codes. This part of ISO 17356 leaves a certain amount of flexibility. On the one hand, the description is generic enough for future upgrades; on the other hand, part of the description is explicitly speci
43、fied and implementation-specific. Any implementation defines all implementation-specific issues. The conformance classes supported by the implementation are indicated precisely, and the issues identified as implementation-specific are documented. Because this description is mandatory, definitions ha
44、ve only been made where the general system strategy is concerned. In all other respects, it is up to the system implementation to determine the optimal adaptation to a specific hardware type. 0.3 Structure of this document 0.3.1 General In the following text, the clauses of this International Standa
45、rd are described briefly: 0.3.2 Clause 3 Architecture of the operating system “OS” This clause gives a survey about the design principles and the architecture of the operating system. BS ISO 17356-3:2005ix0.3.3 Clause 4 Task management This clause explains task management with the different task typ
46、es and scheduling mechanisms. 0.3.4 Clause 5 Application modes This clause describes application modes and how they are supported. 0.3.5 Clause 6 Interrupt processing This clause provides information about the interrupt strategy and the different types of interrupt service routines. 0.3.6 Clause 7 E
47、vent mechanism This clause explains the event mechanism and the different behaviour depending on the scheduling. 0.3.7 Clause 8 Resource management This clause describes the resource management and discusses the benefits and implementation of the priority ceiling protocol. 0.3.8 Clause 9 Alarms This
48、 clause describes the two-stage concept to support time-based events (e.g. hardware-timer) as well as non-time-based events (e.g. angle measurement). 0.3.9 Clause 10 Messages The message handling for intra-processor communication is added to ISO 17356-3. Full message handling is described in ISO 173
49、56-4. The exact subset to be implemented is described in ISO 17356-4. 0.3.10 Clause 11 Error handling, tracing and debugging This clause describes the mechanisms to achieve centralized error handling. It also describes the services to initialize and shut down the system. 0.3.11 Clause 12 Description of system services This clause describes the conventions used for description. 0.3.12 Clause 13 Specification of operating system services This clause describes all operating sys
