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


1.3 Proposer(s)

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 :
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 :
The proposed technical report will complement the specification. It will describe :

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:
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 :

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 :
The size of the market is potentially very important. This market can start and expand in two ways:
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
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)