Matching users requirements (WP2) with technical solutions (WP3)
This is a very wide area where the market is changing and constantly bringing new products. Despite it was quite difficult to cover all technical and physical areas, this Deliverable allowed us to draw the following charts ,which clearly shows :
How the tools meet to the system function requirements,
How the tools meet the technical requirements.
Synoptic table of tools/solution (synoptic.pdf - 11 Ko)
The following remarks reflect the contents of the survey:
The main crucial concern remain that the number of software and functions performed are constantly increasing as well as the hardware solutions. Without formal guidelines the integration of both Software and Hardware which is of key of importance to meet the objective of COMETA will remain very low or almost impossible.
It is obvious that the technology used in today’s equipment, and considering the constant implementations of more and more powerful features thanks to new technologies and portable computers, allow to positively answer the question whether it could meet the requirements listed in the Deliverable D2. The new technologies such as Autojava API or Microsoft Auto PC will probably intensively influence the developments of on board telematic systems in the near future, both for cars and trucks.
The equipment manufacturers need to know exactly which standards they will have to comply with. COMETA’s goal is to supply a set of specifications leading to standardisation.
Regarding sensors it can be said that Truck manufacturers are already using quite sophisticated devices, which are (or will be) centralised and managed by electronic devices the purpose of which is to diagnose and maintain the vehicle. The major problem to be considered so far is nor the availability of sensors neither the type of information they provide but their access and wiring.
In the USA, a standard (J1708) has been defined by the Society of Automotive Engineers (SAE) which makes it possible and easy to integrate an OBC into a vehicle. Its data bus allows the data capture from either the tractor or the trailer and all messages, including their characteristics and priority are precisely defined. Similar works are in progress at the European level.
Regarding smart cards, some systems already include this important feature and some other anticipates offering it as an option. Even though there is a huge number of potential applications for smart cards, we must keep in mind that the use of smart cards is mandatory in the digital tachograph. We must then further investigate the ways of reading information stored on the card and how to possibly store data on the smart card. Two issues need to be clarified.
Will it really be possible to share the functionalities of the smart card with the digital chronotachygraph, such as driver identification.
Assuming that the answer to the previous point is positive, then a limit, which might appear, is not with the architecture and the card management system but with the data storage capacity only.
Generally speaking, several ad hoc solutions have been developed by assembling technical devices and tailor-made software packages based on their compatibility. The emphasis is on developing custom-designed solutions (i.e. customer-owned, not market-oriented) rather than generic products.