Page History

...

The order of definition is not fixed here and it is a challenge.  The technical architecture is basically the intended end result but at the same time a rough architecture needs to be drawn to identify the parts we intend to talk about (data flows, protocols, actors, and so on).
Therefore, the order of these may be slightly different:we likely need to iterate over all of these angles of attack.

1) Technologies used in each system part

...

--> HW / Operating System / Software stack
(likely not very strictly defined -- lots of variability and continuous change)

Example of system parts
- Vehicle ECUs
- Vehicle gateway ECUs
- OEM intermediate servers
- Neutral server
- Developer technologies
- Developer "Developer" endpoints (Web services and/or end-user devices?)
- Final app.  What are the developer final products, i.e. the outcome of 3rd party development.
?  This could be for example web services, and or apps on popular smartphones.

...

What: A block diagram containing typical interacting technical systems (and consequently interacting actors) focusing on the data flow links between them.

This is to identify primarily the links between technical systems that need a defined communication protocol, (and preceeding that of course quality requirements and similar input).

...

For each link in data flow architecture
- (Specify actors involved)
- Identify data set (limitations, + non-functional requirements)
- Identify data protocol

...

Initial

...

ideas

Protocol for Vehicle -> OEM server
- 1) (W3C Gen 2)
- 2) Other?
- Proprietary   MQTT, etc...
3) Are those proprietary protocols (i.e. unspecified in this project)?

(Protocol for Vehicle -> 3rd party servers)
    - Confirm: Is this desired and accepted?
    - This seems one primary aim for W3C Gen2 to cover

OEM server <-> Neutral Server
- 1) W3C Gen 2
- 2) Big-data flow protocolsframeworks à la Apache NiFi

Neutral Server <-> 3rd party developers

= Work I think there are missing standards remaining to do !here?
= ?   ... W3C Gen 2 is likely not enough (see pending requirements first)... I'm thinking of:
- E.g. addressability of      - How to add address individual vehicles, or subsets of a fleet.
     - How to gather aggregate data, etc.
W3C protocol is kind of point-to-point (developer app requests to one specific service, in-vehicle or

- SensorIS specifications are covering some of this, as well as the definition of how to request measurements to be done on the car. 

W3C Gen 2 covers how to fetch a particular value "on demand", which sort of presumes it will deliver the (single) latest known/cached value.
SensorIS covers the definition of a "data-gathering" request to be sent, then processed by car (for possibly some extended time), then reported back.OEM server <-> Neutral Server
= W3C "Gen 2"
= Big-data flow protocols a la Apache NiFi
Neutral Server <-> 3rd party developers