OSGi Vehicle Workshop in Detroit
2007-01-16
Last Thursday (11/01/2006) we met for an automotive workshop at the Delphi headquarters in Troy with participants from Intel, Wind River Systems, Delphi, Renesas, Vetronix, Booz Allen, Ford, GM, Aonix, Siemens VDO, ProSyst, and Telcordia. This workshop was initiated by Kai Hackbarth (ProSyst). Kai is working with a number of companies in the VII project and noticed that there is a lot of interest in OSGi from the participants in this project.
The VII project has a very ambitious goal: it wants to reduce the number of deaths on the American roads and decrease congestion (this is similar to the CVIS project in Europe). To achieve this goal, the American Department of Transport (DOT) wants to build an extensive communication infrastructure that supports vehicle to vehicle communication as well as vehicle to centers communications based on the DSRC communications service. Vehicles will get an on board unit and the roads will get a roadside unit that manages the communication of nearby vehicles. This infrastructure can be used in many different ways. Some examples:
The number of scenarios that can be supported is of course only limited by your imagination. It is therefore that OSGi plays an important role in this project. The life cycle of a car is around 10 years while the life cycle of these types of services is significantly smaller. It is therefore obvious that some form of software downloading and management is required. This is of course the archetypical application area of the OSGi specifications. Maybe the most interesting aspect is that the on board equipment (OBE) can be used for other, commercial, applications as well. This is not a primary goal, but it enables a lot of possibilities!
We had modeled the meeting after the successful Enterprise meeting in August 2006. This meeting resulted in the OSGi Enterprise Expert Group, which will meet in Dublin at the end of this month. The format is simple; some of the participants present their ideas in a 5 minute presentation. This kicks off a discussion where we gather all the different areas that could be relevant for OSGi standardization. This list is then prioritized and further discussed.
We found the following areas of highest interest:
Resource management and hard real time issues
The traditional embedded concerns of resource management and hard real time issues came far ahead of all other items. There exists an OSGi RFC addressing some of these concerns but the focus on server side and desktop applications have moved these concerns to the background. It seems clear that this should be a number one concern for the vehicle group. Interestingly, Aonix presented a very interesting idea. They had create a VM where you could run hard real time applications written in a subset and annotated Java. The code would run in a special memory space that did not require garbage collection. This concept meshes obviously very nicely with the OSGi model of deployment. Special metadata could be used to indicate that specific classes should run on the hard real-time VM.
Vehicle Interface
A vehicle interface provides access to the vehicle configuration and status. There has been work in GST, AMI-C, and the OSGi VEG in this area. Both GST and OSGi use the OSGi Device Management based on OMA DM as the foundation. The complex aspect of the vehicle interface is to model the car. How many chairs, how many axis has each chair, how many windows, where are the seats located. Such an ontology requires vetting by a lot of knowledgeable parties.
HMI
Human-Machine Interface. We have been talking about the HMI since day one but we have never been able to standardize a single HMI. There are developments that seem to make the development of a generic HMI more feasible. Normally, the car manufacturers regard the look and feel of the vehicle as their prerogative but it is becoming clearer that the largest number of applications requires some form of a HMI. Therefore, an OSGi standard should address some way that applications can interact with a user while at the same time allowing as much as possible freedom to the car manufacturer.
Non-Java code integration
The demand to expand from Java to native code becomes larger and larger. In the embedded world it is rarely that there are green-field applications. Embedded systems must work with legacy code that is not easy ported to a Java environment. From the participants it was clear that we need a story how to integrate non-java environments with OSGi. As I discussed elsewhere, I strongly believe that our service registry is a very good mechanism to let different subsystems communicate, regardless of the language that is spoken.
Other
There were several other areas discussed, like: Integration with AutoSAR, handling of safety information, vehicle specifics around provisioning and management, a comprehensive driver model, diagnostics, provisioning of data, navigation model, security, a lightweight form of OSGi, privacy issues, reprogramming ECUs (other processors in the car), distribution, and some none technical areas.
Conclusion
A great deal of time was spent on discussing the OSGi vision of universal middleware and how to get large car companies to buy into the technology. Though the basic OSGi technology has proven itself in a large number of applications, it is not well known in higher echelons. Marketing the technology is hard because there is no product that needs to be sold, what we are selling is a promise. To fulfill this promise we need the participation of the key players in this market: the car manufacturers. Without strong backing from the car manufacturers, few suppliers will invest in pushing a technology like OSGi. We discussed how to get support from the car manufacturers (several were around the table) but that is a difficult issue due the state of the current car industry and lack of knowledge about OSGi in the higher echelons. I guess we have to continue as we do today and hope that the combined results of this work will convince the car manufacturer’s management to invest in our technology.
However, it was clear that OSGi plays an important role in the thinking of many participants of the VII project, just like the European GST and the CVIS project. For these architectures the only option is the OSGi service platform, or otherwise limit the standards to protocols only. Though protocols only can reduce the cost of the OBE, it adds cost in other places because the diversity is increased on the management level. It is therefore not unlikely that in the long run the OSGi service platform becomes a standard component in the car.
Overall, this was very good meeting where both technical and non-technical issues were openly discussed with representatives of the key player; there was a lot of energy in the room. We also intend to follow up this meeting with an OSGi Vehicle Expert Group meeting, further detailing the requirements. It looks like the OSGi technology will happen in our industry, now we only have the small detail of making the vehicle specific specifications left.
Peter Kriens
The VII project has a very ambitious goal: it wants to reduce the number of deaths on the American roads and decrease congestion (this is similar to the CVIS project in Europe). To achieve this goal, the American Department of Transport (DOT) wants to build an extensive communication infrastructure that supports vehicle to vehicle communication as well as vehicle to centers communications based on the DSRC communications service. Vehicles will get an on board unit and the roads will get a roadside unit that manages the communication of nearby vehicles. This infrastructure can be used in many different ways. Some examples:
- Vehicles will transmit roadside information to central management centers which will be digested and dispatched as traffic information.
- When a vehicle breaks, it can send out this information to other vehicles
- Stop lights can send their state to oncoming vehicles
The number of scenarios that can be supported is of course only limited by your imagination. It is therefore that OSGi plays an important role in this project. The life cycle of a car is around 10 years while the life cycle of these types of services is significantly smaller. It is therefore obvious that some form of software downloading and management is required. This is of course the archetypical application area of the OSGi specifications. Maybe the most interesting aspect is that the on board equipment (OBE) can be used for other, commercial, applications as well. This is not a primary goal, but it enables a lot of possibilities!
We had modeled the meeting after the successful Enterprise meeting in August 2006. This meeting resulted in the OSGi Enterprise Expert Group, which will meet in Dublin at the end of this month. The format is simple; some of the participants present their ideas in a 5 minute presentation. This kicks off a discussion where we gather all the different areas that could be relevant for OSGi standardization. This list is then prioritized and further discussed.
We found the following areas of highest interest:
Resource management and hard real time issues
The traditional embedded concerns of resource management and hard real time issues came far ahead of all other items. There exists an OSGi RFC addressing some of these concerns but the focus on server side and desktop applications have moved these concerns to the background. It seems clear that this should be a number one concern for the vehicle group. Interestingly, Aonix presented a very interesting idea. They had create a VM where you could run hard real time applications written in a subset and annotated Java. The code would run in a special memory space that did not require garbage collection. This concept meshes obviously very nicely with the OSGi model of deployment. Special metadata could be used to indicate that specific classes should run on the hard real-time VM.
Vehicle Interface
A vehicle interface provides access to the vehicle configuration and status. There has been work in GST, AMI-C, and the OSGi VEG in this area. Both GST and OSGi use the OSGi Device Management based on OMA DM as the foundation. The complex aspect of the vehicle interface is to model the car. How many chairs, how many axis has each chair, how many windows, where are the seats located. Such an ontology requires vetting by a lot of knowledgeable parties.
HMI
Human-Machine Interface. We have been talking about the HMI since day one but we have never been able to standardize a single HMI. There are developments that seem to make the development of a generic HMI more feasible. Normally, the car manufacturers regard the look and feel of the vehicle as their prerogative but it is becoming clearer that the largest number of applications requires some form of a HMI. Therefore, an OSGi standard should address some way that applications can interact with a user while at the same time allowing as much as possible freedom to the car manufacturer.
Non-Java code integration
The demand to expand from Java to native code becomes larger and larger. In the embedded world it is rarely that there are green-field applications. Embedded systems must work with legacy code that is not easy ported to a Java environment. From the participants it was clear that we need a story how to integrate non-java environments with OSGi. As I discussed elsewhere, I strongly believe that our service registry is a very good mechanism to let different subsystems communicate, regardless of the language that is spoken.
Other
There were several other areas discussed, like: Integration with AutoSAR, handling of safety information, vehicle specifics around provisioning and management, a comprehensive driver model, diagnostics, provisioning of data, navigation model, security, a lightweight form of OSGi, privacy issues, reprogramming ECUs (other processors in the car), distribution, and some none technical areas.
Conclusion
A great deal of time was spent on discussing the OSGi vision of universal middleware and how to get large car companies to buy into the technology. Though the basic OSGi technology has proven itself in a large number of applications, it is not well known in higher echelons. Marketing the technology is hard because there is no product that needs to be sold, what we are selling is a promise. To fulfill this promise we need the participation of the key players in this market: the car manufacturers. Without strong backing from the car manufacturers, few suppliers will invest in pushing a technology like OSGi. We discussed how to get support from the car manufacturers (several were around the table) but that is a difficult issue due the state of the current car industry and lack of knowledge about OSGi in the higher echelons. I guess we have to continue as we do today and hope that the combined results of this work will convince the car manufacturer’s management to invest in our technology.
However, it was clear that OSGi plays an important role in the thinking of many participants of the VII project, just like the European GST and the CVIS project. For these architectures the only option is the OSGi service platform, or otherwise limit the standards to protocols only. Though protocols only can reduce the cost of the OBE, it adds cost in other places because the diversity is increased on the management level. It is therefore not unlikely that in the long run the OSGi service platform becomes a standard component in the car.
Overall, this was very good meeting where both technical and non-technical issues were openly discussed with representatives of the key player; there was a lot of energy in the room. We also intend to follow up this meeting with an OSGi Vehicle Expert Group meeting, further detailing the requirements. It looks like the OSGi technology will happen in our industry, now we only have the small detail of making the vehicle specific specifications left.
Peter Kriens
Add a comment
| Previous Posts | Archives |
|---|---|