Design concerns

Some initial collection of topics to cover, concerns and challenges, and how to structure the definition of the "big picture" Vehicle Data reference architecture.

0) Initial assumed technical  architecture ("block architecture")

What: Draw and list technical components that may be involved in the architecture.  This includes both hardware and software components.

We can start with some of our inputs we may use their proposed assumptions (ExVE and other) as initial input.  However:

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:

1) Technologies used in each system part

What: List typical hardware and software components.  This may be quite abstract at times (e.g. the exact hardware of course differs) but in that case list the assumed type of component.

--> 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 final products, i.e. the outcome of 3rd party development.
This could be for example web services, and apps on popular smartphones.

2) Data flow architecture

What: A block diagram containing typical interacting technical systems (and consequently interacting actors).

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).

3) Data protocols

What: Based on the block diagram, and performance/quality/content requirements for each link, propose appropriate data protocol standards.

The choice may be affected also by the communicating software components 

Vehicle buses → ECUs -> "Vehicle Gateway" (example EE architecture)
brief and for completness

Vehicle -> OEM server
(Vehicle -> 3rd party servers)
- ?
OEM server <-> Neutral Server
Neutral Server <-> 3rd party developers

For each actor in data flow architecture:
- Identify needs/requirements from that actor

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

Initial idea

Vehicle -> OEM server
- (W3C Gen 2)
- Other?
- Proprietary (i.e. unspecified in this project)

(Vehicle -> 3rd party servers)
- ?

OEM server <-> Neutral Server
- W3C Gen 2
- Big-data flow protocols

Neutral Server <-> 3rd party developers

= Work to do!
= ? ... W3C Gen 2 is likely not enough (see requirements first)...
- E.g. addressability of individual vehicles, aggregate data, etc.

OEM server <-> Neutral Server
= W3C "Gen 2"
= Big-data flow protocols a la Apache NiFi

Neutral Server <-> 3rd party developers