telematics api for java me jsr298 - oracle software downloads | oracle...

Telematics API for Java ME JSR298

Proposed Final Draft

Dave Kim, SK Telecom

November 1, 2007

Telematics API for Java ME

i

JSR298 Telematics API for Java ME Specification (“Specification”)

Specification Lead: SK Telecom, Inc. (“Specification Lead”)

NOTICE; LIMITED LICENSE GRANTS

Specification Lead hereby grants You a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under the Specification Lead's applicable intellectual property rights to view, download, use and reproduce the Specification only for the purpose of internal evaluation, which shall be understood to include developing applications intended to run on an implementation of the Specification provided that such applications do not themselves implement any portion(s) of the Specification. The Specification contains proprietary information of the Specification Lead and may only be used in accordance with the license terms set forth herein.

Subject to the reciprocity requirement set forth below Specification Lead also grants You a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable limited license (without the right to sublicense) under any applicable copyrights or patent rights it may have in the Specification to create and/or distribute an Independent Implementation of the Specification that: (a) fully implements the Specification without modifying, subsetting or extending the public class or interface declarations whose names begin with "java" or "javax"; or their equivalents in any subsequent naming convention adopted by Specification Lead through the Java Community Process, or any recognized successors or replacements thereof; (b) implement all required interfaces and functionality of the Specification; (c) only include as part of such Independent Implementation the packages, classes or methods specified by the Specification; (d) pass the technology compatibility kit ("TCK") for such Specification; and (e) are designed to operate on a Java platform which is certified to pass the complete TCK for such Java platform. For the purpose of this agreement the applicable patent rights shall mean any claims for which there is no technically feasible way of avoiding infringement in the course of implementing the Specification. Other than this limited license, You acquire no right, license, title or interest in or to the Specification or any other intellectual property rights of the Specification Lead.

You need not include limitations (a)-(e) from the previous paragraph or any other particular "pass through" requirements in any license You grant concerning the use of Your Independent Implementation or products derived from it. However, except with respect to implementations of the Specification (and products derived from them) by Your licensee that satisfy limitations (a)-(e) from the previous paragraph, You may neither: (i) grant or otherwise pass through to Your licensees any licenses under Specification Lead's applicable intellectual property rights; nor (ii) authorize Your licensees to make any claims concerning their implementation's compliance with the Specification in question.

The license provisions concerning the grant of licenses hereunder shall be subject to reciprocity requirement so that Specification Lead's grant of licenses shall not be effective as to You if, with respect to the Specification licensed hereunder, You (on behalf of yourself and any party for which You are authorized to act with respect to this Agreement) do not make available, in fact and practice, to Specification Lead and to other licensees of Specification on fair, reasonable and non-discriminatory terms a perpetual, irrevocable, non-exclusive, non-transferable, worldwide license under such Your (and


ii

such party's for which You are authorized to act with respect to this Agreement) patent rights which are or would be infringed by all technically feasible implementations of the Specification to develop, distribute and use an Independent Implementation of the Specification within the scope of the licenses granted above by Specification Lead. However, You shall not be required to grant a license:

1. to a licensee not willing to grant a reciprocal license under its patent rights to You and to any other party seeking such a license with respect to the enforcement of such licensee's patent claims where there is no technically feasible alternative that would avoid the infringement of such claims;

2. with respect to any portion of any product and any combinations thereof the sole purpose or function of which is not required in order to be fully compliant with the Specification; or

3. with respect to technology that is not required for developing, distributing and using an Independent Implementation.

Furthermore, You hereby grant a non-exclusive, worldwide, royalty-free, perpetual and irrevocable covenant to Specification Lead that You shall not bring a suit before any court or administrative agency or otherwise assert a claim that the Specification Lead has, in the course of performing its responsibilities as the Specification Lead under JCP process rules, induced any other entity to infringe Your patent rights.

For the purposes of this Agreement: "Independent Implementation" shall mean an implementation of the Specification that neither derives from the reference implementation to the Specification ("Reference Implementation") source code or binary code materials nor, except with an appropriate and separate license from licensor of the Reference Implementation, includes any of Reference Implementation's source code or binary code materials.

This Agreement will terminate immediately without notice from Specification Lead if You fail to comply with any material provision of or act outside the scope of the licenses granted above.

TRADEMARKS

SK Telecom is a registered trademark of SK Telecom Corporation. SK Telecom Corporation 's product names are either trademarks or registered trademarks of SK Telecom Corporation Your access to this Specification should not be construed as granting, by implication, estoppel or otherwise, any license or right to use any marks appearing in the Specification without the prior written consent of SK Telecom Corporation or SK Telecom's licensors.

No right, title, or interest in or to any trademarks, service marks, or trade names of Sun or Sun's licensors, is granted hereunder. Sun, Sun Microsystems, the Sun logo, Java, J2ME, and the Java Coffee Cup logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.


iii

DISCLAIMER OF WARRANTIES

THE SPECIFICATION IS PROVIDED "AS IS". SPECIFICATION LEAD MAKES NO REPRESENTATIONS OR WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE OR THAT ANY PRACTICE OR IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADE SECRETS OR OTHER RIGHTS. This document does not represent any commitment to release or implement any portion of the Specification in any product.

THE SPECIFICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION THEREIN; THESE CHANGES WILL BE INCORPORATED INTO NEW VERSIONS OF THE SPECIFICATION, IF ANY. SPECIFICATION LEAD MAY MAKE IMPROVEMENTS AND/OR CHANGES TO THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THE SPECIFICATION AT ANY TIME. Any use of such changes in the Specification will be governed by the then-current license for the applicable version of the Specification.

LIMITATION OF LIABILITY

TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SPECIFICATION LEAD OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO ANY FURNISHING, PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN IF SPECIFICATION LEAD AND/OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

You will indemnify, hold harmless, and defend Specification Lead and its licensors from any claims arising or resulting from: (i) Your use of the Specification; (ii) the use or distribution of Your Java application, applet and/or clean room implementation; and/or (iii) any claims that later versions or releases of any Specification furnished to You are incompatible with the Specification provided to You under this license.

REPORT

You may wish to report any ambiguities, inconsistencies or inaccuracies You may find in connection with Your use of the Specification ("Feedback"). To the extent that You provide Specification Lead with any


iv

Feedback, You hereby: (i) agree that such Feedback is provided on a non-proprietary and non-confidential basis, and (ii) grant Specification Lead a perpetual, non-exclusive, worldwide, fully paid-up, irrevocable license, with the right to sublicense through multiple levels of sublicensees, to incorporate, disclose, and use without limitation the Feedback for any purpose related to the Specification and future versions, implementations, and test suites thereof.


v

- DOCUMENT HISTORY -

Revision Date Author Comments

Early Draft 2007-04-09 Dave Kim Initial Draft.

Early Draft 1st update 2007-05-24 Dave Kim Added components Defined monitoring feature

Early Draft 2nd update 2007-05-27 Dave Kim Demonstrate relationship with JSR256 Modify the usage instruction for diagnostics

Early Draft 3rd update 2007-07-01 Dave Kim Added Use Cases

Public Review Draft 2007-08-09 Dave Kim Reformatted the document Newly added TSP model Added Security consideration

Public Review Draft Revision 1.1

2007-09-05 Dave Kim Changes from additional EG review, e.g. Nokia

Public Review Draft Revision 1.2

2007-09-12 Dave Kim Added component names list Added “WindowLock” Component

Public Review Draft Revision AB

2007-10-22 Dave Kim Added Vehicle component example (Appendix C) Modify the requirement for OEM to implement vehicle components

Proposed Final Draft 2007-10-30 Dave Kim Modify name of some APIs of diagnostics class and component manger class


vi

- TABLE OF CONTENTS -

Telematics API for Java ME.......................................................................................... 1

1. Introduction ............................................................................................................. 1

2. Scope ......................................................................................................................... 2 2.1. Vehicle Component........................................................................................................................2

2.2. Diagnostics......................................................................................................................................4

2.3. TSP..................................................................................................................................................4

3. Architecture ............................................................................................................. 5 3.1. Vehicle Component........................................................................................................................6

3.2. Diagnostics......................................................................................................................................7

3.3. TSP..................................................................................................................................................7

3.3.1. Conceptual Model ...............................................................................7

3.3.2. Flow ....................................................................................................8

3.4. Accessibility ...................................................................................................................................9

4. Requirements ..........................................................................................................11

5. Use case for Vehicle Operation and Maintenance .............................................. 12

5.1. USE CASE 1: User Configuration ..............................................................................................12

5.2. USE CASE 2: Anti-theft System.................................................................................................13

5.3. USE CASE 3: Locating Vehicle..................................................................................................13

5.4. USE CASE 4: Temperature Control ...........................................................................................14

6. Appendix A – Security Consideration ................................................................. 16

6.1. Automotive Operations ................................................................................................................16

6.2. Using the MIDP 2.0 Security Framework ..................................................................................16

6.2.1. Acquire vehicle component ............................................................... 16

6.2.2. Operate vehicle component .............................................................. 17

7. Appendix B – TSP Flow Example ........................................................................ 19

7.1. Round ............................................................................................................................................19

7.1.1. Round packet type ............................................................................ 20

7.1.2. Round time........................................................................................ 20


vii

7.1.3. Round exceptions ............................................................................. 20

7.1.4. Round exception process.................................................................. 20

7.1.5. Round type........................................................................................ 20

7.2. Session ..........................................................................................................................................20

7.2.1. Session time ..................................................................................... 21

7.2.2. Session exceptions ........................................................................... 21

7.3. Scenario.........................................................................................................................................21

7.3.1. Scenario Flow ................................................................................... 21

7.3.2. Multi scenario process....................................................................... 21

7.3.3. Scenario time .................................................................................... 22

7.3.4. Scenario exceptions.......................................................................... 22

8. Appendix C – Vehicle component Example ........................................................ 23

9. Appendix C – References...................................................................................... 25


viii

TABLE OF FIGURES

Figure 1. Vehicle Components page 3

Figure 2. JSR-298 Structure page 5

Figure 3. class diagrams page 6

Figure 4. Door Component page 7

Figure 5. TSP conceptual model page 8

Figure 6. the concept of “Flow” page 9

Figure 7. USE CASE 1: User Configuration page 12

Figure 8. USE CASE 2: Anti-theft System page 13

Figure 9. USE CASE 3: Locating Vehicle page 14

Figure 10. USE CASE 4: Temperature Control page 15

Figure 11. Acquire vehicle component page 17

Figure 12. Operating Vehicle Components page 19

Figure 13. TSP flow example page 20


ix

- Preface -

Who this is written for: This documents audience is intended for those who would be building a Telematics API for Java ME. Those who may be building content may also find this document useful.

Distribution Rights This document is owned by the SKT Corporation and must not be publicly distributed.Copyright © SKT 2001. All rights reserved.

Document Information: For further information and copies of other documents and requirements referred to herein, contact:

Dave Kim

Mobile Platform & Standards / SK telecom

[email protected].


1

1. Introduction This document defines JSR298 Telematics API for Java ME. The main purpose of JSR298 is to be able to provide automotive telematics services through use of this specification on embedded devices that are using Java ME platform.

The goal is to standardize specification in order to provide automotive telematics services using embedded devices with Java ME as their base platform. This specification defines methods for controlling and obtaining diagnostic information and conditions on various components built in to the vehicle.

Therefore, this document will provide specifications required for controlling various equipments built into the vehicles as well as obtaining diagnostic information on these components and vehicle conditions.

Automotive components are defined as equipments that are accessible for drivers including airbag, door, window, and brake. This specification is applicable to telematics-specific automotive terminals as well as other various portable devices including cellular phones and PDAs.


2

2. Scope

JSR298 standardization covers vehicle components, diagnostics and telematics service protocol (TSP). Vehicle components are devices equipped on the vehicle. The diagnostics API provides how to gather diagnostic information.

2.1. Vehicle Component Many telematics services utilize various devices and components that are built in to the vehicle. These built in components types and operational methods will vary depending on the model and type of the vehicle. This specification is written for telematics service for a general vehicle type and targets standardization of components that are commonly installed on various types of vehicles. From the list of these commonly existing automotive components, the key components that are considered as requirements for the telematics services are listed in the table below.

This section defines the properties for each automotive component. It describes the possible states and operations. “Possible Operation” indicates the controls or settings for each component. “States or Value [Unit]” indicates the current state of the equipment and measured values. “Possible Operation” specified in the “States or Value [Unit]” are the values changed or configured by the “Possible Operation”. “States or Value [Unit]” that does not have “Possible Operation” specified is not controlled or configured through JSR298 but can be changed by other various reasons.

Interface name Component name Possible Operations States or Value [Unit] Set Mode Enabled/Disabled

Airbag DriverAirbag PassengerAirbag - Fired off/Not Fired off

AirConditioning AirConditioning Turn on/off On/Off

Antenna Antenna Extend/Retract Extended/Retracted

Battery Battery - Electricity Level [Voltage]

Brake Brake - Engaged/Not Engaged

BrakeFluid BrakeFluid - Fluid Level [Percentage]

DashboardIllumination DashboardIllumination Level set Illumination Level [Percentage]

Reset 0 (Zero) DifferentialOdometer DifferentialOdometer

Incremental Distance [Kilometer]

Lock/Unlock Locked/Unlocked Door

DriverDoor PassengerDoor Open/Close Opened/Closed

Engine Engine Start/Stop Running/Stopped

EngineCoolant EngineCoolant - Level [Percentage]

EngineOil EngineOil - Level [Percentage]

ExteriorTemperature ExteriorTemperature - Temperature [Degree Celsius]

FogLights FogLights Turn on/off On/Off

Fuel Fuel - Fuel Level [Liter]

HazardSignalLights HazardSignalLights Turn on/off On/Off

HeadLights HeadLights

Set Mode On High Beam/On Low Beam/Off

Horn Horn Ring/Stop Ringing/Mute


3

Interface name Component name Possible Operations States or Value [Unit] HVACFan HVACFan Set Mode Straight/Low/Defrost/Off

InteriorTemperature InteriorTemperature - Temperature [Degree Celsius]

KeyHole KeyHole -

Locked – key removed Inserted – key inserted ACC - accessory devices can be working ON - electrically more expandable devices can be working and maybe engine has been started Start – engine is starting.

Pan Angle [-30~30 Degree] Mirror

DriverSideMirror PassengerSideMirror InsideMirror

Tilt Angle [-30~30 Degree]

MirrorDefrost DriverSideMirrorDefrost PassengerSideMirrorDefrost InsideMirrorDefrost

Turn on / off On/Off

ObstacleDistance ObstacleDistance - Distance [Kilometer]

Odometer Odometer - Distance [Kilometer]

ParkingBrake ParkingBrake - Engaged/Not Engaged

ParkingLights ParkingLights Turn on / off On/Off

RearDefrost RearDefrost Turn on / off On/Off

Slide Position [Millimeter]

Lift Angle [0~180 Degree] Seat DriverSeat PassengerSeat

Tilt Angle [-30~30 Degree]

SeatBelt DriverSeatBelt PassengerSeatBelt

- Engaged/Not Engaged

SeatHeaterCooler DriverSeatHeaterCooler PassengerSeatHeaterCooler

Turn on / off On/Off

SecurityAlert SecurityAlert Issue/Cancel Issued/Not Issued

Shutter Shutter Set transparency Transparency

Extend Extended Rate [Percentage] SteeringWheel SteeringWheel

Tilt Angle [0~180 Degree]

SteeringWheelHeater SteeringWheelHeater Turn on / off On/Off

SunRoof SunRoof Open / Close Opened/Closed

Tire

FrontLeftTire FrontRightTire RearLeftTire RearRightTire

- Air pressure

TurnSignalLights TurnSignalLights Set Mode Left/Right/Off

Speedometer Speedometer - Speed [Kilometer per Hour]

WindowLock DriverWindowLock PassengerWindowLock

Lock / Unlock Locked/Unlocked

Window DriverWindow PassengerWindow

Set Position Opened Rate [0~100]

Set Mode Fast/Slow/Off Wiper

FrontWiper RearWiper Set Interval Interval Time [Milliseconds]

Figure 1. Vehicle Components


4

The possible states for these components listed above are defined in the specification and the control methods for these components are defined as an API. The access methods to these APIs are also defined as a standard and included in the specification. The specification defines APIs to get the list of the supported components and to restrict accesses for the unsupported components. In order to apply the JSR298, OEM does not need to implement for all components in the above table, but should implement for all of components that can be supported in the vehicle.

2.2. Diagnostics The actual automotive components equipped on the vehicle are in the form of Electronic Control Units (ECU). Components such as window wiper, vehicle door, windows, and headlights are connected to their respective ECUs. When the user is controlling a specific vehicle component, it is in fact transmitting control commands to the ECU connect to this component.

These ECUs that enable component control mechanism also transmits information on internal state of the vehicle which is also known as vehicle diagnostic code. The method for retrieving diagnostic code is different for each vehicle model as well as ECU manufacturer but JSR298 defines this as a standard API and includes it in the specification.

From analyzing this diagnostic code, it is possible to obtain the status of automotive component connected to the ECU, operational status of connected components, connection status between ECU and the automotive component, connection status between ECUs, and status of ECU itself.

From the vehicle diagnostic code, the actual code types and represented value provided by the vehicle, interpreted results, and methods for retrieving these codes are all different depending on the manufacturer and the model of the vehicle. The JSR298 standardizes APIs for retrieving the diagnostic codes that are defined by OBD2 standard.

2.3. TSP This JSR 298 document provides a simple conceptual model for telematics service protocol and describes detail specification of TSP.


5

3. Architecture JSR298 consists of standards in reference to vehicle components and diagnostics for automotive telematics services. The API sets for JSR298 is to be implemented based on, at least Connected Limited Device Configuration (CLDC), version 1.1 and will be used to develop applications for automotive telematics services.

Figure 2. JSR-298 Structure

The vehicle components section and vehicle diagnostic section do not have any connection between them and will be defined separately.


6

Figure 3. class diagrams

3.1. Vehicle Component Each vehicle components are defined as interfaces with multiple inheritances from both VehicleComponent interface and SensorConnection interface that is from JSR256 Mobile Sensor API specification. The components that are defined in this manner are listed in the table in section 2.1. Below is an example that illustrates the relationship between interfaces for Door interface.


7

Figure 4. Door Component

Other components are also defined in a similar structure as the one shown above. JSR298 standardizes specialized control methods as an API for each component and subset of JSR256 specification is used for retrieving the state of the components and to monitor the status changes of these components. Therefore, vehicle component object can be obtained as an object of an implemented class for VehicleComponet interface through use of getComponent() in ComponentManager class, and at the same time, it can be retrieved using Connector.open() in an implemented class of SensorConnection interface.

The subset of this Mobile Sensor API has the following relationship with the full Mobile Sensor API specification.

� The subset of Mobile Sensor API considers vehicle component as a sensor and only has a functionality to get current state and monitor the state change.

� The JSR298 is defined and aligned so that it would not conflict with contents in Mobile Sensor API.

3.2. Diagnostics

JSR298 defined separate Diagnostic class for automotive diagnostic API specification. Diagnostic class provides functionality to obtain vehicle diagnostic code that was requested and transmitted by the ECU.

OEM can set a policy for accessing these vehicle diagnostic API. However, in order to restrict service application from retrieving these diagnostic codes, UnsupportedOperationException must be raised when the application attempts to access Diagnostics class object.

getDiagnostics () that retrieves vehicle diagnostic codes is defined as an asynchronous (non-blocking) API since acquiring the diagnostic code can be a time consuming process. Vehicle diagnostic code is delivered through the listener that is registered to getDiagnostics(). If cancelGetDiagnostics () is called before listener is invoked, the process for retrieving the vehicle diagnostic code can be stopped. cancelGetDiagnostics () must immediately stop the operation of retrieving the vehicle diagnostic code that is in progress.

3.3. TSP 3.3.1. Conceptual Model

The simple conceptual telematics service diagram is as below.


8

Figure 5. TSP conceptual model

As the figure illustrates, telematics service is accomplished through communication with server and vehicle terminal. Vehicle terminal gathers information, inquires vehicle context, controls vehicle equipments, and handles user requests, while transferring requests to server and receiving responses from telematics server.

Both telematics terminal and server can trigger telematics service communication. Terminal sends almost requests to server and gathers useful information or direction from server and informs vehicle context to the server. Also server sends public notice/guidance to the terminal and performs remote device management service.

JSR298 does not specify a packet format for any communication and packet sequences for specific telematics service. They are in the scope of implementation details for telematics service. XML-based

packets or specific binary packets can be used for telematics services, and the packet sequence should be defined by thetelematics service provider for its own service.

3.3.2. Flow

This specification imports concept of “Flow” abstractly as below figure.


9

Figure 6. the concept of “Flow”

In this specification, expressed Flow as above figure may describe below attributes abstractly.

1. There MUST be start and end.

2. It can be shown start, end and progress.

3. It can be controlled Flow start, termination and delay.

4. A Flow may be consisted of combination of Smaller Flows.

5. Flow can be defined as several priorities and operated simultaneously and forced prior operation.

These attributes will be described as Classes and APIs with JAVA. Please refer to JavaDoc about details of defined classes and APIs.

3.4. Accessibility

Additional item that OEMs must consider when implementing the vehicle components and diagnostic features as discuss in previous sections is to define a policy that restricts accessibility to these components and features. OEM can determine and apply access policy as required to restrict accessibility to these components and features.


10

In order for the OEM to limit or restrict access to vehicle components and automotive diagnostic features, SecurityException must be thrown when the API with its accessibility restricted as defined by the policy is called. These restrictions required for security purposes can be divided into many levels as required to limit accessibility. The following is an example of creating restriction levels.

� Automotive manufacturer level: Permitted to access all vehicle components and their functionalities.

� Service center and automotive service related business level: Permitted to access most of the components and their functionalities.

� User level: Permitted to access only the components and its features that is required for telematics service application.


11

4. Requirements

JSR298 assumes Java ME platform as basis of the implementation and the prerequisite for implementing the contents of this specification is, at least, Connected Limited Device Configuration (CLDC), version 1.1 or higher.


12

5. Use case for Vehicle Operation and Maintenance

This document describes scenarios for each use case involving providing driver with information and controls of the vehicle.

Terminal Device is defined as a device used by the driver to control and communicate with the vehicle. Terminal Device can be devices that are equipped on the vehicle such as dashboard gauges, vehicle control switches and other controls, various displays, and remote controller.

Monitor Device applies to program modules that are used to communicate with the vehicle for processing user requests through use of Terminal Device.

Car Device represents vehicle equipment and/or device that is actually being controlled or operated.

5.1. USE CASE 1: User Configuration Driver A who shares the vehicle with his/her family members wants to adjust the positions of the driver’s seat and the mirrors according to his/her desired configuration rather than having to manually adjust it back every time someone else uses the car. Driver A stores the current configuration of personalized seat and mirror positions in the terminal device.


13

Figure 7. USE CASE 1: User Configuration

This is a use case for storing and maintaining configuration values of personalized information such as seat height, sitting position, adjusted mirror positions, and etc. Information storing is to provide users with personalized services using these stored values.

5.2. USE CASE 2: Anti-theft System Driver A parked the vehicle in an underground parking facility where it is isolated. While leaving the parking facility, the driver activated the vehicle security system for anti-theft purposes.

Later in the day, Driver A received a signal on the remote terminal device indicating an abnormal condition. When he/she got back to the vehicle, even though the vehicle was still parked at the same location where he/she left it, there were signs of forced entry. After examining the recordings from surveillance camera equipped inside the vehicle, Driver A found a recorded video of someone trying to open the vehicle with forced entry and he/she was able to notify this event to the proper authorities.

Figure 8. USE CASE 2: Anti-theft System

This is a use case to illustrate scenario where the security of the vehicle has been compromised due to forced entry or external shock/impact to the vehicle. The entry to the vehicle is restricted after it is in security mode and it does not allow anyone from entering the vehicle at this state. It is also possible to sound the audible alarm according to the situation. Notification of security breach is sent to the vehicle owner or appropriate authorities including policy and security personnel through telephony SMS.

5.3. USE CASE 3: Locating Vehicle Driver A parked the vehicle at the parking facility. When the driver returned to the parking facility, it was very difficult to locate his/her car due to high number of similar vehicles parked in the same facility. Using the remote control device, Driver A turned on the emergency light and horn, the driver was able to


14

locate his/her vehicle.

Figure 9. USE CASE 3: Locating Vehicle

If the vehicle is equipped with GPS device, this GPS device applied to this scenario to remotely transmit the current location of the vehicle to the driver.

5.4. USE CASE 4: Temperature Control Driver A parked his/her car at an outdoor parking lot in the middle of the summer. With the interior of the vehicle completely sealed (with closed doors and windows), the interior temperature reaches a point where it is very uncomfortable for the driver to get in and operate the vehicle. Driver A wants to adjust the interior temperature of the vehicle to a desired setting and using remote control, the driver adjusts the vehicle air conditioning unit to preferred temperature.


15

Figure 10. USE CASE 4: Temperature Control

This scenario assumes that the Terminal Device for controlling the temperature is an external controller such as remote control rather than internal controls equipped inside the vehicle. This use case illustrates a scenario where the user controls the vehicle remotely using a Terminal Device before it is operated


16

6. Appendix A – Security Consideration Preface

This document, Telematics Security is an addendum to the Telematics API (JSR-298) for Java ME. The appendix is written for implementation of the Telematics API, especially with the Mobile Information Device Profile, Version 2.1 (JSR-118) and Connected Device Configuration (JSR-036), Version 1.0 or later specifications. The above specifications can be found at http://www.jcp.org/jsr/detail/298.jsp, http://www.jcp.org/jsr/detail/118.jsp and http://www.jcp.org/jsr/detail/36.jsp, respectively.

All terms are defined at the above specification except where noted.

Scope

The purpose of this document is to identify security concern for the Telematics API for Java ME, and to specify the permission and the method where the permission influences when they are used in conjunction with MIDP 2.1 or CDC.

This specification does not specify the implementation detailed action and things which are implemented already by the other security framework, such as MIDP 2.1 or CDC 1.0.

6.1. Automotive Operations

Operating vehicle components have influence on safety, so all automotive operations, operator MUST have sufficient authority. This JSR provides the several interfaces representing automotive devices to access and operate vehicle components. All interfaces are to be obtained as this JSR specifies.

The application can manage the vehicle devices using the component objects, but in some cases, the operations need to be limited to use. To limit all or some of the operations, the methods of the component throws a SecurityException if the application does not have the required permission to operate the vehicle component.

6.2. Using the MIDP 2.0 Security Framework

If Telematics API for Java ME works together with MIDP 2.x platform, MIDP’s security framework must be used as defined below.

6.2.1. Acquire vehicle component

As referred above, acquiring vehicle component need to be protected by the permission which grants the operation. Following table specifies a related permission and the methods which are protected by the permission.

Permission name Methods protected by this permission


17

javax.microedition.automotive.Component ComponentManager.getComponet()

Connector.open()

Figure 11. Acquire vehicle component

6.2.2. Operate vehicle component

Operating vehicle component must be granted by the permission which is needed for the specific action. So, each permission and the influenced methods are defined below.

Permission name Methods protected by this permission

javax.microedition.automotive.VehicleComponent.AirConditioning

AirConditioning.setMode()

javax.microedition.automotive.VehicleComponent.AirBag

AirBag.setMode()

javax.microedition.automotive.VehicleComponent.Antenna

Antenna. setMode ()

javax.microedition.automotive.VehicleComponent.DashboardIllumination

DashboardIllumination.setValue()

javax.microedition.automotive.VehicleComponent.DifferentialOdometer

DifferentialOdometer. setValue ()

javax.microedition.automotive.VehicleComponent.Door.

Door.setMode ()

javax.microedition.automotive.VehicleComponent.Engine

Engine.setValue ()

javax.microedition.automotive.VehicleComponent.FogLight

FogLight.setMode()

javax.microedition.automotive.VehicleComponent.HVACFan

HVACFan.setMode()

javax.microedition.automotive.VehicleComponent.HazardSignalLight

HazardSignalLight.setMode ()

javax.microedition.automotive.VehicleComponent.Headlights

Headlights.setMode()

javax.microedition.automotive.VehicleComponent.Horn

Horn.setMode()

javax.microedition.automotive.VehicleComponent.Mirror

Mirror.setValue()

javax.microedition.automotive.VehicleComponent. MirrorDefrost.setMode()


18

MirrorDefrost

javax.microedition.automotive.VehicleComponent.ParkingLight

ParkingLight.setMode()

javax.microedition.automotive.VehicleComponent.RearDefrost

RearDefrost.setMode()

javax.microedition.automotive.VehicleComponent.Seat

Seat.setValue()

javax.microedition.automotive.VehicleComponent.SeatHeaterCooler

SeatHeaterCooler.setMode()

javax.microedition.automotive.VehicleComponent.SecurityAlert

SecurityAlert.setMode()

javax.microedition.automotive.VehicleComponent.Shutter

Shutter.setValue()

javax.microedition.automotive.VehicleComponent.SteeringWheel

SteeringWheel.setValue()

javax.microedition.automotive.VehicleComponent.SteeringWheelHeater

SteeringWheelHeater.setMode()

javax.microedition.automotive.VehicleComponent.SunRoof

SunRoof.setMode()

javax.microedition.automotive.VehicleComponent.TurnSignal

TurnSignal.setMode()

javax.microedition.automotive.VehicleComponent.Window.lock

Window.setMode()

javax.microedition.automotive.VehicleComponent.Window.move

Window.setValue()

javax.microedition.automotive.VehicleComponent.Wiper

Wiper.setValue()

Figure 12. Operating Vehicle Components


19

7. Appendix B – TSP Flow Example Classified Flow for TSP can be used as below figure.

Figure 13. TSP flow example

Scenario: Flow as abstracted service use case, it consisted of several sessions Flow.

Session: Lower unit Flow is regularized from divided smaller scenario, it is made up several rounds Flow.

Round: Defined minimum unit Flow of information and request / reply communications needed in session Flow.

7.1. Round

Flow made up communication with round packet. It is made up one pair of transmission and reception.

Local process

Local process

ScenarioScenarioScenarioScenario FlowFlowFlowFlow

Request/Notification packet

Acknowledge packet

RequestRequestRequestRequest roundroundroundround

Acknowledge packet

ReplyReplyReplyReply roundroundroundround

SessionSessionSessionSession 2222

Acknowledge packet

Request roundRequest roundRequest roundRequest round

Round Time

Session Time



SessionSessionSessionSession 1111


20

It is not concern of received packet’s contents, receptor MUST send acknowledge packet.

7.1.1. Round packet type

1) Request / reply packet: Transmitter requests any local process to receptor or delivers any information on purpose.

2) Acknowledge packet: After receiver received request / reply packet, receiver MUST send acknowledge packet to the transmitter as soon as possible. Acknowledge packet has a meaning of notifying a packet reception to transmitter basically.

7.1.2. Round time

It is elapsed time from sending request / reply packet to receiving acknowledge packet. If there is no acknowledge packet after defined time limit, transmitter considers this round to be fail. This case is called Round timeout.

7.1.3. Round exceptions

1) Round timeout: If there is no acknowledge packet after defined time limit, transmitter considers this round to be fail.

2) Packet error: This case is that there is something different format, contents, or unreadable in received packet. As receiver recognizes these errors, receiver have to send acknowledge packet with error information.

3) Channel error: This case is transmission/reception failure because of round channel interruption.

7.1.4. Round exception process

If any round failed, transmitter could retry that round or other adequate process according to the service provider’s definitions of scenario or session included failed round.

7.1.5. Round type

1) Call (Request) round: In this round, transmitter sends any information to receiver or requests a local process.

2) Response round: In this round, receiver executes request local process and sends the results to transmitter.

7.2. Session

A session consists of call round, correspondence local process, and response round. Response round may not exist when there is no local process.


21

7.2.1. Session time It is elapsed time from ending call round to starting response round. Caller measurement time is the basis. Response round cannot start in defined time limit, that is session timeout.

7.2.2. Session exceptions

1) Session timeout: This may be ignored according to session definition. Although session timeout ignored, acknowledge packet of response round MUST be sent for right closing.

2) Local process error: This case is occurred when system do not execute local process or have an error during processing. In this case, system MUST send error information to transmitter using response round.

7.3. Scenario

Scenario is a Flow consisted of sessions and local processes. A Scenario is correspondence with a completion telematics service use case.

7.3.1. Scenario Flow

1) Start: Scenario MUST have one more session. Starting point of first session may be regarded as scenario start. It includes start information of scenario in call round packet of first session.

2) Finish: Scenario has to define completion conditions. For example, all defined sessions are successfully completed.

3) Termination: In this specification, system can terminate scenario actively depending on cases.

7.3.2. Multi scenario process

1) Concurrent process: Modeling scenarios in this specification can be executed at once. But it is not inbound of this specification.

2) Priority process: In this specification, system is able to suspend lower priority scenario when higher priority scenario occurred. Opposite case, lower priority scenario does not be executed during executing higher priority scenario.

3) Priority of scenarios: Telematics service on basis of this specification MUST define more 3 priority levels distinctively. When system executes lower priority scenario, system can decide concurrent or priority process for higher priority scenario. But, lower priority scenario does not be executed during executing higher priority scenario.


22

� Emergency level: Assign critical scenarios as like emergency rescue, vehicle robbery, etc.

� Control level: Assign middle level scenarios as like management, control, delivering important information, etc.

� Service level: Assign low level scenarios as like user convenience services.

7.3.3. Scenario time It is elapsed time of sequentially connected two sessions. If next session can not start in predefined time limit, this case is scenario timeout.

7.3.4. Scenario exceptions 1) Scenario termination: This case is that system terminates scenario Flow actively because of several reasons. Also this case include it for multi scenario process that system terminates lower priority scenario according to higher priority scenario occurred


23

8. Appendix C – Vehicle component Example A vehicle component can be used as below figure (in this case, AirConditioning)

import java.io.IOException;

import javax.microedition.io.Connector;

import javax.microedition.automotive.*;

import javax.microedition.sensor.*;

/**

* Vehicle Component Example : AirConditioning

*/

public class AirConditioningTest implements DataListener, ConditionListener{

private static final int BUFFER_SIZE =1;

private AirConditioning airConditioning = null;

// 1. Open connection with AirConditioning component

public AirConditioningTest () {

//Vehicle component Open

try {

airConditioning = (SensorConnection)Connector.open("sensor: AirConditioning");

} catch (IOException e1) {

e1.printStackTrace();

}

}

// 2. Get vehicle data : Synchronous API test

public void testSync() {

//Read data

Data dataArr[] = airConditioning.getData(BUFFER_SIZE);

int state[] = dataArr[0].getIntValues();

int onStatus = state[0];

System.out.print("on status = "+ onStatus);

}

// 3. Set data listener : Asynchronous API test

public void testAsync() {

airConditioning.setDataListener(this, BUFFER_SIZE);

}


24

// 4. Set Condition : Get notification when Driver-side door is opened

public void testConditions() {

ChannelInfo acChannelInfo[] = airConditioning.getSensorInfo().getChannelInfos();

Channel acChannel = null;

acChannel = airConditioning.getChannel(acChannelInfo[0]);

acChannel.addCondition(this,

new LimitCondition(AirConditioning.ON, Condition.OP_EQUALS));

}

// 5. DataListener

public void dataReceived(SensorConnection sensor, Data[] data, boolean isDataLost)

{

int state[] = data[0].getIntValues();



}

// 6. ConditionListener

public void conditionMet(SensorConnection sensor, Data data, Condition condition) {

System.out.print("ChannelInfo:"+ data.getChannelInfo().getName() + " ");

int state[] = data[0].getIntValues();



}

}


25

9. Appendix C – References

Connected Limited Device Configuration (CLDC)

http://jcp.org/aboutJava/communityprocess/final/jsr030/index.html

Mobile Information Device Profile (MIDP)

http://jcp.org/aboutJava/communityprocess/final/jsr037/index.html

Mobile Information Device Profile, Next Generation (MIDP 2.0)

http://jcp.org/aboutJava/communityprocess/first/jsr118/index.html

Security for GSM/UMTS Compliant Devices Recommended Practice. Addendum to the Mobile Information Device Profile version 2.0. JSR-118 Expert Group, Version 1.0, Nov 5, 2002.

http://jcp.org/aboutJava/communityprocess/first/jsr118/index.html

Advanced Multimedia Supplements, version 1.1.

http://jcp.org/en/jsr/detail?id=234

Java Technology for Wireless Industry (JTWI).

http://jcp.org/en/jsr/detail?id=185

Connected Device Configuration, version 1.0.

http://www.jcp.org/jsr/detail/36.jsp

Connected Device Configuration, version 1.1.

http://www.jcp.org/jsr/detail/218.jsp

OBD II

http://www.obdii.com/

- End of Document -

telematics api for java me jsr298 - oracle software downloads | oracle...

Documents