Releases: eclipse-kuksa/kuksa.invehicle
Eclipse Kuksa 0.2.0 release
The Eclipse Kuksa 0.2.0 release's main focus is on on integrating the cloud and in-vehicle with a holistic authorization and authentication system based on Keycloak. Apart from that, several other interesting features and improvements have been introduced.
On the cloud side we started moving the deployment layer to a terraform and helm charts based approach. The App Store now has consent functionality, is integrated with the IDE and uses Keycloak for authentication and authorization. Some minor improvements have been implemented for the InfluxDbConnector and the deployment infrastructure.
On the In-Vehiclen side the Keycloak integration has been implemented and also extended to the direct access API. In addition to that, the in-vehicle platform received improvements on the Viss-Server implementation, the App-Manager and, separated from the software stack, version 0.2.0 contains also a hardware layout of a dongle to retrofit cars with in-vehicle functionality. With version 0.2.0 message buffering is now available and allows to bridge network interruptions.
The Kuksa IDE now provides typescript extensions to establish an end-to-end workflow in the Eclipse Kuksa ecosystem from the IDE via the Appstore and Hawkbit to the device. As the In-Vehicle gateway can be run on different operating systems (Raspbian, AGL, Debian, Apertis, etc.) or hardware architectures (arm64 etc.), In-Vehicle applications will be provided in a generic way via docker images. Therefore, a build script allows to generate target-specific docker images. Based on a generated .yaml config file and a Python-based script, the resulting docker images can then be published to the app store and hawkbit respectively. The typescript extensions can be used in either a local VSCode instance or on cloud-based IDEs such as Eclipse Che 7 (based on Eclipse Theia) or GitPod.
Eclipse Kuksa 0.2.0-M1 release
The Eclipse Kuksa 0.2.0 release main focus is on on integrating the cloud and in-vehicle with a holistic authorization and authentication system based on Keycloak. Apart from that several other interesting features and improvements have been introduced. On the cloud side we started moving the deployment layer to a terraform and helm charts based approach. The App Store now has consent functionality and is integrated with the IDE.
On the in-vehicle side the Keycloak integration has been implemented and also extended to the direct access API. Separated from the in-vehicle software stack version 0.2.0 contains also a hardware layout of a dongle to retrofit cars with in-vehicle functionality.
The Kuksa IDE is now realized as an Eclipse Che Plugin to establish an end-to-end workflow in the Eclipse Kuksa ecosystem from the IDE via the Appstore and Hawkbit to the device. As the In-Vehicle gateway can be run on different operating systems (Raspbian, AGL, Debian etc.) or hardware architectures (arm64 etc.), In-Vehicle applications will be provided in a generic way via docker images. Therefore, a build script allows to generate target-specific docker images. Based on a generated .yaml config file and a Python-based script, the resulting docker images can then be published to the app store and hawkbit respectively.
Eclipse Kuksa 0.1.0 release
The first Eclipse Kuksa 0.1.0 release contains various software across the domains in-vehicle, cloud, apps, and IDE and focuses primarily on providing fundamental functionalities to setup a cloud environment as well as target devices that interact within this environment.
Device owners within this environment can select applications over an Appstore and install them on their target device. Such applications can exchange data with or store data in the cloud. Therefore, required software on the device is directly included within images built for (ARM) platforms such as the Raspberry Pi3 via provided build scripts. Furthermore, developers can publish new applications to the Appstore and register new devices for specific Appstore users.
0.1-M1
The first Kuksa In-Vehicle Milestone release 0.1-M1 contains:
- agl-kuksa - Scripts to automate AGL build system with the meta-kuksa layers.
- elm327-visdatafeeder - ELM 327 app that reads OBDII data from the vehicle and feeds data to the w3c-visserver.
- kuksa-hawkbit - Barebone API for connecting with Hawkbit. Will be shortly replaced with kuksa-appmanager.
- w3c-visserver-api - W3C Vehicle Information Specification API.
- direct-access-api - Enables sending CAN messages from the cloud to vehicle using Websocket.
- datalogger-http - Example app that sends data from the vehicle to an Eclipse Hono instance with http.
- datalogger-mqtt - Example app that sends data from the vehicle to an Eclipse Hono instance with mqtt.
- remoteAccess - Example app that subscribes to control topic with Hono and receives commands sent.
- kuksa-appmanager - Hawkbit appmanager which deploys in-vehicle apps as docker conatiners and more..
- email-notifier - Example app that talks to an email-server and sends e-mails to the configured email address. Used at the moment only for internal demos.