J Consortium Project Proposal (Draft)
High Integrity Profile/Automotive
1. Source of the Proposed Project
1.1 Title
High Integrity Profile Extension for Automotive Control Applications (HIP/Automotive)
1.2 Date Submitted
TBS
1.3 Proposer(s)
Trialog.
25 rue du Général Foy
75008 Paris, France
Contact Point : Antonio Kung, Director
Email: antonio.kung@trialog.com
2. Process Description for the Proposed Project
2.1 Project Type (Development or Revision)
D - Addendum to High Integrity Profile, and
D - Technical Report
2.2 Type of Document
Addendum to High Integrity Profile plus Automotive-specific Technical Report. The technical report will focus on specific aspects which need not be standardized, such as recommendations on how the intended profile is supported by legacy code and legacy tools.
2.3 Definitions of Concepts and Special Terms
ECU : Electronic Control Units
2.4 Expected Relationship with Approved Reference Models, Frameworks, Architectures, etc.
The OSEK-VDX specification will be a reference model (see www.osek-vdx.org)
2.5 Recommended J CONSORTIUM Technical Committee (TC) Working Group.
WG-1, RTJWG, working in concert with the High Integrity Profile Project Group.
Available resources :
- Trialog will provide a technical editor for this effort.
- Aonix
- U.Karlsruhe. U.Karlsruhe intends to apply for general membership
- PSA. PSA intends to apply for general membership
- Centro Riserche Fiat. intends to apply for general membership
- Mecel AB. Mecel AB intends to apply for general membership
Note that Trialog, U.Karlsruhe, Mecel AB will jointly work on a reference implementation and test suite.
Note that PSA and Centro Riserche Fiat will assess/validate the reference implementation through typical automotive applications.
2.6 Anticipated Frequency and Duration of Meetings
6 meetings from now to February 2001, most of them colocated with J consortium meetings or specific events on embedded systems and automotive. Duration is one or two days.
Teleconference will be organized as needed.
2.7 Target Date for Initial Public Review (Milestone 4)
February 2001
2.8 Estimated Useful Life of Specification or Technical Report
15 years
3. Business Case for Developing the Proposed Specification or Technical Report
3.1 Description
The proposed specification describes the suitable profile for the use of Java for automotive control systems such as engine control systems.
This profile will describe mechanisms and APIs which :
- provide the level of integrity expected in automotive control applications,
- allow for the right level of CPU performance (e.g. native code generation), and allow the development of device drivers in Java.
- address typical timing constraint issues for automotive control systems,
- target the type of electronic configurations that are in use in the industry: 16 and 32 bit microcontrollers and memory footprints ranging from 64 Kbytes to several hundred Kbytes (ROM) for the whole system.
- address programming language issues such as
- memory management issues (e.g. garbage collection, persistent objects),
- synchronization issues (e.g. priority inversion),
- support for asynchronous external events (e.g. support of interrupt handlers in Java),
- address distributed communication and multiplexing needs (e.g. use of CAN, subsystem management),
The proposed technical report will complement the specification. It will describe :
- how the profile can rely on existing standards of the automotive industry, in particular OSEK/VDX, or diagnosis standards,
- how legacy C code and legacy tools (e.g. OSEK/VDX tools) can be supported
3.2 Existing Practice and the Need for a Specification
Today vehicles include an increasing number of electronics systems. It has been estimated by Dataquest that the average semiconductor content of a vehicle will reach $240 by 2001, with consumption of DSPs, microcontrollers and microprocessors reaching $4.9 billion. Typical configurations consist of interconnected Electronic Control Units (ECUs) which may be connected through several buses. One possible bus is the "entertainment/infotainment" bus which connects subsystems such as radio, telephone, and navigation. Another one is the control bus which connects ECUs such as the ABS, the engine control, or the transmission control subsystem. A vehicle such as the Volvo S80 includes "18 ECUs connected via six networks: a low-speed body electronics CAN bus (125kbit/s), a high-speed powertrain CAN bus (250kbit/s), and four other networks."
ECUs are part of an embedded system market which is very fragmented since it ranges from systems based on 4 bit microcontrollers (e.g. a light switch) to 128 bit processors (e.g. game consoles). Today 4 to 16 bit microcontrollers make up the bulk of the market in terms of volume (around $10 billion per year or higher), while 32 bit and higher systems count for less than 10% of the market. It is however expected that 32 bit systems will expand at a much higher rate than 16 or 8 bit microcontrollers.
Most ECUs in the automotive control systems market are currently 8 to 16 bit systems. An increasing number of 32 bit systems will be included in the next generation of vehicles, but for cost and reliability reasons, such systems are likely to be designed using single chip or system on a chip approaches. This implies significant constraints in acceptable memory footprints.
ECUs often have to deal with duty cycles of several ms. Engine control subsystems for instance have to manage the engine cycle which has a duration that depends on the round per minute (RPM). At 6000 RPM, the engine cycle is 20 ms, which means that the ECU has to handle timing constraints on the order of several ms. In addition, ECUs exchange control data through the bus. The exchange period can be as low as several ms. The CAN bus is a typical type of control bus currently in use. Note that in many cases, engineering decisions made by OEMs may add further real-time constraints, such as the implementation of a serial link or a multiplexing link by software to lower cost.
ECUs are typically designed and developed by OEMs according to requirements set up by car manufacturers. Such requirements include a detailed description of expected interfacing capabilities, and in particular a detailed description of data transmitted to the ECUs or to be transmitted by the ECUs. In many cases, OEMs are not informed of the entire vehicle message system, as the car manufacturer may wish to protect trade secrets.
Until quite recently OEMs had in most cases total freedom in the design of ECUs, including the software, the processor and the hardware. However car manufacturers now anticipate a need to provide very precise requirements, in particular at the software level. There is a trend toward the specification of more global functions made possible by the networking and multiplexing capabilities of today’s vehicles, for example an automatic gear shift function could sit partly in the transmission control ECU and partly in the engine control ECU. Thus a car manufacturer may wish to subcontract an OEM for the development of only the software component (e.g. the global gear shift function or the part sitting in the engine control) or for the production of an incomplete ECU (e.g. the engine control part without the automatic gear shift part). This approach not only allows the implementation of global functions, but it can also further protect the car manufacturers trade secrets.
To address this trend, the automotive industry is looking for technologies that will facilitate the software development integration process. It has identified the need to provide guidance on the transition towards advanced electronic architectures in the following ways:
- Pushing from the start for the definition of open systems, with the definition of corresponding interfaces (APIs). This has allowed the definition of the OSEK/VDX standard (www.osek-vdx.org), probably one of the most successful undertaking concerning RTOS standardization in the software industry today.
- Pushing for the use of advanced software engineering methods, such as OMT and UML, and approaches promoting software reuse, such as object-oriented programming.
Java could be the cornerstone technology on which the infotainment bus could be built. The AMIC initiative (www.ami-c.com) on multimedia interoperability, is investigating an open technology in the multimedia area based on Java.
Java has not yet been considered for automotive control systems because of technology issues, like memory footprints, real-time support and high integrity support. It is believed that an agreed standard meeting the requirements listed in §3.1 will allow the automotive industry to take advantage of the object-orientation, reusability, robustness and portability attributes associated with Java.
To make this happen however, a standardized specification has to be available as the automotive industry practically only works through open standards. This is the reason for submitting the specification work within the J consortium.
We expect the resulting document to be stable for a significant duration. The automotive industry only works on stable standards which have a duration of 10 years or more.
This proposal originates from the AJACS (Applying Java to Automotive Control Systems) consortium. AJACS is partially funded by the European commission. Note that AJACS will develop at least one reference implementation and a test suite.
3.3 Implementation Impacts of the Proposed Specification
3.3.1 Development Costs
The estimated development costs for the specification and technical report is 160 men-days :
- 60 men-days corresponding to 6 technical meetings
- 20 men-days corresponding to 10 teleconferences
- 80 men-days for the writing of the Specification and Technical report
The incremental costs of developing this specification will be borne by the committee members, whose organizations have made a business decision to proceed with this work.
3.3.2 Impact on Existing or Potential Markets
The benefit of an agreed standard on the automotive market will be twofold :
- it will be able to take advantage of the object-orientation, reusability, robustness and portability attributes associated with Java. It will make it easier for automotive manufacturers to reuse the same software components independently of hardware platforms provided by different suppliers. It will make it easier for OEMs to reuse software components for different manufacturers
- new subcontracting relationships will be made easier between car manufacturers and OEMs such as instances where only software components are subcontracted.
The size of the market is potentially very important. This market can start and expand in two ways:
- OEMs today which are struggling with software diversity could switch to Java for productivity reasons. Such decision would involve switching all developments for all car manufacturers to Java. This means that the resulting-volume will be very high.
- Car manufacturer could start requiring the use of Java for automotive control, with OEMs having to comply. The resulting number of involved OEMs can be very significant as it is directly related to the number of ECUs in a car. Further there are typically two suppliers for each ECU.
The automotive industry is also known to be conservative and slow to move. We believe it will first go for experimentation phases before taking industrial decisions. Taking into account that vehicle development life cycle is typically 4 years or more, this means that high-volume can only be expected in 5-6 years. This is consistent with what happened with the CAN bus or with OSEK-VDX technology.
3.3.3 Costs and Methods for Conformity Assessment
It is anticipated that the techniques and costs for verification and compliance with the proposed specification will be similar to those of other computer environments. These techniques will be developed and the costs borne by those implementing the proposed specification, as well as other commercial organizations that may specialize in conformity assessment.
The Technical Report will describe applicable conformance assessment methods. It will contain the necessary and sufficient testing information for assessing conformity to this specification.
3.3.4 Return on Investment
The organizations that wish to participate in the development of the proposed specification are responsible for the performance of any cost/benefits analysis as may be required by their internal policies and procedures prior to making such commitments.
3.4 Legal Considerations
3.4.1 Patent Assertions
Patent calls will be made to identify assertions of patent rights in accordance with the relevant J CONSORTIUM policies and procedures.
The proposer is not aware of any patent assertions that may be made.
3.4.2 Dissemination of the Specification or Technical Report
Drafts of this document will be disseminated electronically. Dissemination of the final specification and report will be in accordance with J Consortium policy and procedures as the documents become the property of J CONSORTIUM.
Note that the technical report will make reference to the OSEK-VDX specification which is subject to copyright from OSEK-VDX.
4. Related Specifications Activities
4.1 Existing Specifications
OSEK-VDX
Real-Time Core Extensions for the Java Platform (draft)
4.2 Related Specifications Activity
New versions of OSEK-VDX
WG-1, Real-Time Core Extensions for the Java Platform (draft)
WG-1, High Integrity Profile (HIP)
4.3 Recommendations for Coordinating Liaison
WG1 and HIP
4.4 Recommendations for Close Liaison
(already covered above)