 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 298: Telematics API for JavaTM ME
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: This JSR defines the API set for Telematics Service on mobile devices. Please direct comments on this JSR to the Spec Lead(s) Team
NOTE: the following updates were made to the original proposal. 2006.06.20: The summary was changed from "This JSR defines the API set for Telematics services on embedded devices." to "This JSR defines the API set for Telematics Service on mobile devices." Initial Expert Group Membership: Sun Microsystems Supporting this JSR: Sun Microsystems Section 2: Request
2.1 Please describe the proposed Specification:This JSR is designed to provide a standard API set to control the car devices and diagnose status of the car on the current and the next generation of embedded devices. The primary goal of this JSR is to define service-oriented API set providing standardized interface to Telematics service applications.In the end, the API which is for car device control and diagnosis aims for collecting information of car status and controlling the car devices to support telematics services. One of the core functionalities to enable telematics service is to control and monitor the car devices through the communication protocol provided by the internal car network such as TCP/IP, CAN, MOST, GPIO, and DIO. Based on this control/monitor functionality, operators and manufacturers can provide various services to car owners or drivers equipped with embedded devices such as handsets or built-in telematics terminals. So the goal of this JSR is to provide a standard API set to control and diagnose car devices with close streamline with J2ME technology.
The proposed JSR API will support: The target devices will be J2ME-enabled embedded devices, with connection to the car control network through wire or wireless radio such as Bluetooth or RFID. So, the devices with this JSR can be viewed as a service interface between service provider and the car. This JSR is a service-oriented API set related to Telematics service and may have optional API sets dedicated for before-market telematics devices in order to provide more detailed control over car devices including AV unit and proprietary car diagnostics modules. Based on the proposed JSR, the various actors of Telematics including service operators, embedded device vendors, automotive manufacturers, and application/solution developers can find a stable and standard way to build the Telematics services modules. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The target is CLDC/MIDP and next generation CDC-based platforms. OSGi could be too heavy for CLDC. This JSR, on the other hand, defines the same API set for both CDC and CLDC trying to avoid the service API fragmentation between the two platforms. Current trend in Java ME is to integrate CDC and CLDC to a single platform. Developing separate CDC specific JSR and CLDC specific JSR may cause the fragmentation issues in integrated platforms. Hence, JSR298 targets to define Telematics API suitable for both CDC and CLDC. 2.5 What need of the Java community will be addressed by the proposed specification?Various operators and car makers started or plan to start telematics services from the simple 911 emergency call to complicated driving guidance service. And the service will become more attractive and profitable through joint work with automotive industry. Although the basic telematics service set is identified by operators and automotive industry such as AMI-C, the feasible Java standard is not yet designed or defined for the service through Java Community Process. Especially, the car interface API?s is not covered by any JSR at all. The interface to car devices is not yet standardized from the view of service providers and embedded device vendors, and regarded as an important asset to automotive manufacturers, which makes the car device control/diagnostics difficult to be implemented. This may hinder the introduction of new value-adding services related to car management. By providing a uniform API sets designed for embedded devices, the existing telematics solutions and services can be modified in more inter-operable way and various new kind of Java-based telematics service will emerge more easily.
Possible use cases enabled by this JSR include: Although OSGi will include vehicle-related APIs in the next specification through its Vehicle Expert Group activity, it is not tailored to the mobile services and Java, and the telematics-related functionalities proposed in OSGi should be more refined and evaluated by this JSR as JSR232 (Mobile Operational Management). Currently, SK Telecom is communicating with Hyundai Motors and Renault Samsung Motors to join this JSR as expert group members in order to take inputs from auto industry. 2.6 Why isn't this need met by existing specifications?JSR 179 Location API can be a basic building-block for the telematics, but it only mainly focuses on the GPS and location information. Currently, there is no Java specification for telematics. To provide the real telematics services in actuality, It is recommended to control the car devices such as doors, engine, power train in case of emergency besides the location information. The OSGi specification will include telematics-related bundles as the package after Release 4. Even though it might be a reference for the design of this JSR, OSGi can be too heavy for the majority of embedded devices. Launching the OSGi application framework on top of J2ME is too heavy and expensive. Considering that JSR232 migrates the original OSGi core system onto mobile handsets and J2ME area, this JSR can be viewed as an refined adaptation from OSGi VEG(Vehicle Expert Group) APIs. Basically, JSR298 is a service-oriented API set related to Telematics service, regardless of the underlying application framework or management framework. JSR232 deals with Framework but JSR298 is to define the service API set. We think JSR232 defines and provides a management framework, so JSR298 can be bundled as a component tailored for JSR232 if necessary. Embedded device could be a mobile handset and it is meaningful work to run on mobile handset since there currently exists contents that diagnose car status through OBDII port on car. We anticipate it is possible to control the car devices using mobile handset through Bluetooth or other wired/wireless mechanism further. This JSR assumes that it is provided as an extension of J2ME MIDP (or CDC). 2.7 Please give a short description of the underlying technology or technologies:The automotive API will be an example for a convergence of heterogeneous industries : IT and automotive fields. The knowledge from the two fields should be closely streamlined with each other. The API should provide a uniform way to handle the car devices such as door, speedometer, car diagnostics module and so on. Since there are various communication channels including GPIO, CAN, MOST, and so on, the API itself should provide an abstract way to be neutral to various configurations. GCF(General Connection Framework) introduced in J2ME can be used as an building block to implement the communication protocols. Furthermore, some kind of layered approach similar to communication protocol stack (logical device layer, physical device layer, and connection layer) might be necessary for this kind of abstraction. As a start point for the discussion to interface with car, the OBD-II specification (http://www.obdii.com) can be used to define the basic interface, because all cars in US have this interface by the regulation. A user could get status information about power train, engine, tiers etc. through embedded devices using API that based on the OBD-II standard. 2.13 Please describe the anticipated schedule for the development of this specification.August 2006: EG Formed 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.We will license to all interested parties. TCK and RI will be licensed separately. For TCK we will charge a single one time fee of max $50000 USD and an annual maintenance fee, max $20000 USD/pa. TCK will include the binary environment and source code of the test suite. Maintenance fee covers limited basic support, first level TCK appeals process, bug fixes and updates, which are due to changes in the specification, and when made available by the specification lead. Major new releases (esp. follower JSR) might be subject to additional single one time fee. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: SK Telecom Co., Ltd Name of Contact Person: Young M. Park E-Mail Address: ypark Telephone Number: +82 2 6100 2666 Fax Number: +82 2 6100 7908 Specification Lead: Young M. Park E-Mail Address: ypark Telephone Number: +82 2 6100 2666 Fax Number: +82 2 6100 7908 Initial Expert Group Membership: Sun Microsystems Supporting this JSR: Sun Microsystems Section 2: Request NOTE that Section 2 has been extensively updated from this original proposal. 2.1 Please describe the proposed Specification:This JSR is designed to provide a standard API set to control the car devices and diagnose status of the car on the current and the next generation of embedded devices. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)This specification is targeted for the Java ME platform on embedded devices. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The target is the CLDC/MIDP and the next generation CDC-based platforms. NOTE that Section 2 has been extensively updated from this original proposal. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?Various operators and car makers started or plan to start telematics services from the simple 911 emergency call to complicated driving guidance service. And the service will become more attractive and profitable through jointed co-work with automotive industry. Although the basic telematics service set is identified by operators and automotive industry such as AMI-C, the feasible Java standard is not yet designed or defined for the service through Java Community Process. Especially, the car interface API?s is not covered by any JSR at all. The interface to car devices is not yet standardized from the view of service providers and embedded device vendors, and regarded as an important asset to automotive manufacturers, which makes the car device control/diagnostics difficult to be implemented. This may hinder the introduction of new value-adding services related to car management. NOTE that Section 2 has been extensively updated from this original proposal. 2.6 Why isn't this need met by existing specifications?JSR 179 Location API can be a basic building-block for the telematics, but it only mainly focuses on the GPS and location information. Currently, there is no Java specification for telematics. To provide the real telematics services in actuality, It is recommended to control the car devices such as doors, engine, power train in case of emergency besides the location information. The OSGi specification will include telematics-related bundles as the package after Release 4. Even though it might be a reference for the design of this JSR, OSGi can be too heavy for the majority of embedded devices. Launching the OSGi application framework on top of J2ME is too heavy and expensive. Considering that JSR232 migrates the original OSGi core system onto mobile handsets and J2ME area, this JSR can be viewed as an refined adaptation from OSGi VEG(Vehicle Expert Group) APIs. JSR232 doesn?t satisfy sufficiently for car interfaces on diagnostic and control. Unlike JSR232, this JSR proposes API that could manage car diagnostics and controls using embedded devices. So, this JSR doesn?t overlap with JSR 232. Embedded device could be a mobile handset and it is meaningful work to run on mobile handset since there currently exists contents that diagnose car status. This JSR assumes that it is provided as an extension of J2ME MIDP (or CDC). NOTE that Section 2 has been extensively updated from this original proposal. 2.7 Please give a short description of the underlying technology or technologies:The automotive API will be an example for a convergence of heterogeneous industries : IT and automotive fields. The knowledge from the two fields should be closely streamlined with each other. The API should provide a uniform way to handle the car devices such as door, speedometer, car diagnostics module and so on. Since there are various communication channels including GPIO, CAN, MOST, and so on, the API itself should provide an abstract way to be neutral to various configurations. GCF(General Connection Framework) introduced in J2ME can be used as an building block to implement the communication protocols. Furthermore, some kind of layered approach similar to communication protocol stack (logical device layer, physical device layer, and connection layer) might be necessary for this kind of abstraction. As a start point for the discussion to interface with car, the OBD-II specification ( http://www.obdii.com) can be used to define the basic interface, because all cars in US have this interface by the regulation. A user could get status information about power train, engine. NOTE that Section 2 has been extensively updated from this original proposal. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)"javax.microedition.Automotive" will be a good candidate. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?None 2.10 Are there any security issues that cannot be addressed by the current security model?None 2.11 Are there any internationalization or localization issues?Support for a sufficient set of character encodings might be required. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?None 2.13 Please describe the anticipated schedule for the development of this specification.July 2006: EG Formed NOTE that Section 2 has been extensively updated from this original proposal. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The working interactions will be primarily email communications, with occasional teleconferences/video conferences as appropriate. Face-to-face meetings, which will be tele/videoconferenced, will be arranged as needed and as appropriate. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.The transparency plan is: 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.Both RI and TCK will be delivered as stand-alone packages. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.We will license to all interested parties. TCK and RI will be licensed separately.
NOTE that Section 2 has been extensively updated from this original proposal.
Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.N/A 3.2 Explanation of how these items might be used as a starting point for the work.N/A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
