We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


Looking at the CVII tech stack landscape (which includes input from multiple projects led by companies and organizations) I see a lot of diversity.  Some diversity is good but it appears a bit disorganized. 

Goal setting

  • Aim to produce PoC to prove and test out uncertain areas
  • Aim to produce close to production-ready implementations for areas that are not uncertain
  • Agree upon requirements for real-world (production) usage 
    • Preferred technologies, programming languages and runtimes
    • Non-functional requirements (performance, environments)
    • Development support requirements (CI / static-analysis tools, etc.)
    • Quality improving requirements (testing etc.)

Are current implementations too monolithic?

Can we build an ecosystem of pluggable components (as discussed many times), and in the process accelerate the creation of complete systems as well?

Current challenges


- Not a clear enough focus on reusable components.
- A wide diversity of programming languages and runtimes
- Not identifying what the requirements are for production-level code
- Not identifying where we have "formal" (defined/documented) interfaces as opposed to internal interfaces.

I'd like our community to start discussing some of these aspects to build a more homogeneous approach to the development.

(answer / discuss)

A) Have we agreed on the list of required components, their responsibilities and interfaces?

Tech Stack overview 

B) What, in your view, are acceptable choices (and preferred choices)
 for programming languages and runtimes:
  - In-cloud
  - In-vehicle

Today's ECUsNext-stage ECUs (domain controllers, central computers)Cloud (computers not in-vehicle)Development tools, code-generators, converters etc.

"Vehicle cloud computing"

(think about next-next gen)






Javascript / NodeJS


.NET, C#, ...

Haskell, Erlang, ...

C) In existing architecture pictures (e.g. CCS), and framework implementations (e.g. iot-event-analytics/vehicle-edge/KUKSA.val, AOS) which interfaces:

  - are documented ?
  - need to be documented ?
  - do NOT need to be documented (= internal / implementation detail) ?

Inspiration from these architecture pictures and other pages:

Completion of technology definition / implementation
Component NameProgramming language / runtimeRequired/consumed interfacesProvided Interfaces
Kuksa.VAL:PythonUses various bindings, socketCAN, ...
VISS-like interface also for writing data into KUKSA?
VISS protocol(?)
VSS Feeder (multiple)
= StateStorage db interfacedepends on input type (CAN, etc.)
State StorageSQLite database-SQL
OVDS Client (ccs client)
GoVISS protocol
OVDS Server
Go= StateStorage db interface

(CCS): LiveSim
GoData in OVDS Database format
WAII:Service ManagerGo(internal)(internal)
WAII:Server CoreGo(internal)(internal)
WAII:AGTGo-(internal)  HTTP?
WAII:ATGo-(internal)  HTTP?
WAII:MQTTGo(internal, VISS-like communication)-
WAII:WebSocketGo(internal, VISS-like communication)-
WAII:HTTPGo(internal, VISS-like communication)-
OVDS DatabaseSQLite.  Probably should be production-level time series database

  • No labels