SOUP Solution architecture overview
Table of contents:
Solution architecture blueprint
The following is an architecture blueprint for a system software update solution highlighting the Bosch Digital services (colored in blue), as well as personas and components required from the customer side (colored in grey).
Integrations on the Management UI/API side
System Responsible
The System Responsible analyzes which systems are in the field, creates new system updates using system update definitions (also called recipes), and monitors their application in the field. The main interface used by the System Responsible is the UI.
Module Responsible
The Module Responsible mainly uses Bosch IoT Rollouts to upload new artifacts and assemble them in distribution sets which can then be referenced by system update definitions (recipes) for system updates. Moreover, the Module Responsible has an overview of the overall system constellation their module is part of.
For more information see Bosch IoT Rollouts service.
Continuous integration / continuous delivery (CI/CD)
The CI/CD pipeline facilitates the creation and upload of software update artifacts (e.g. *.bin-, *.hex-files) as well as all related collaterals (e.g. release notes, license texts) to the System Software Update service. Additionally, system update definitions (recipes) can also be created, after successfully testing of the system.
Identity Provider (IdP)
The Identity is responsible for managing users and roles. There is a pre-defined set of roles available from the System Software Update and Bosch IoT Rollouts service which need to be assigned to the respective users. By default, the Bosch Identity Management is used, however, integrating an external IdP is possible.
Sign and Encrypt
To ensure confidentiality and integrity of the software update artifacts, the files can be packaged, encrypted, and signed before being uploaded to Bosch IoT Rollouts. In addition, system update definitions (recipes) can be signed.
For more information see Sign and Encrypt service.
Integrations on the Install API side
Proxy
It is recommended that the endpoint for systems in the back-end is owned by the customer. This brings several advantages:
Full control of the endpoint, incl. certificate lifecycle and TLS configuration,
reduced lock-in risk, and
improved debugging capabilities for gateway to back-end communication.
The proxy can also handle the certificate-based authentication of the gateways.
System update app
The system update app enables the following two use cases:
Performing updates for non-connected systems i.e., retrieve and cache available updates from the SOUP service, update the system, and provide feedback about the offline system update to the SOUP service.
Fulfilling user interaction-related legal obligations (e.g. for consent collection, and release notes presentation).
End user
A person who interacts with the system update app e.g. service technician, installer, customer. The end user needs to be informed about available updates and/or potential updates for existing systems in the field.
System
A set of interconnected modules which are usually connected to either the internet or the system update app via a gateway. The gateway is responsible for the validation of the system update (e.g. checking the signature), for distributing the update to the modules and for collecting their feedback.