Stay on top of your rollouts with our email notifications
Want to track the approval path of software packages and rollouts? Sibros has launched email notifications for you to easily follow the important steps leading to the start of a rollout.
Package and rollout approvals are important steps in the chain of actions of an OTA update.
With our new email notifications feature, rollout and package approval requests trigger the sending of an email notification to the designated approvers. Additionally, status changes (approval, abortion, scheduled start) are immediately conveyed to owners and approvers via email.
Our screenshot shows an email notifying a user about an approved rollout:
In the past, if approval was requested on packages and rollouts, the owner would have to manually seek approval from approvers, provide them a link, and follow up to get status updates.
This created the potential for delays in the release process, ambiguity for the approver on what they need to approve, and manual overhead for the owners. Now email notifications for significant events streamline the process because approvers automatically receive emails that redirect them to the site of action, and the owners and approvers are kept up-to-date on changes in the status of approvals or rollouts.
Events that trigger email notifications:
All required users have approved the Package; the Package can be deployed.
Package Owner & Package Approvers
All required users have approved the Rollout; the Rollout can be started.
Scheduled Rollout Started
The Rollout has started at the scheduled time.
Rollout Owner & Rollout Approvers
The Rollout has been aborted.
Package Approval Request
Approval needs to be provided for the Package.
All pending Package Approvers
Rollout Approval Request
Approval needs to be provided for the Rollout.
All pending Rollout Approvers
Configurable File Logging
Use rules to handle files as you wish
Data logging is one of the most important enablers of the software-defined vehicle and its importance in automotive can’t be overstated. We are now introducing configurable file logging, which opens up important new capabilities for your logging needs.
Define and upload
It starts with your ability to define “System Log Rules” within logging configurations. These log rules allow Deep Logger to locate important files and subsequently upload them to the cloud. The workflow is simple: You define the file locations in the data map, and the files to upload are selected when a log rule is created.
Stream, save, or export
In the next step, we provide a choice of how to deal with network data and custom signals. You can now choose whether logged data is streamed “live” to the cloud, or saved to a local file to be uploaded at a later time. If you choose to store file logs locally, you can upload them later, using a manual trigger in the cloud. Additionally, you have the option to export files to formats that are standard in the automotive industry.
Our screenshot shows the window to specify log rules:
Flow in our Web Portal
We have established flows in our Web Portal that make dealing with configurable file logging as easy and seamless as possible. If a log rule is configured for manual upload to the cloud, you can use a button to trigger the upload of files with the data related to this log rule. You can use another button to export the log for a certain log rule; this button comes with a dropdown to choose the desired file format. And finally, you can track the download or export of logs, to always know the status of the process.
Our screenshot shows the Web Portal with log rules and buttons to upload file data as well as to export data into a desired file format.
The benefits of configurable file logging are numerous. To just state three examples, you can now:
Scale to even more complex vehicle architectures
To be even more flexible and extensible, Sibros' Deep Updater needs to function across multiple machines and orchestrate OTA campaigns with the cloud. To this end, we are constantly adding features and now provide the following:
Be in control with command history, recent commands, and repeated runs
Remote commands are an important enabling feature for the software-defined vehicle. We have introduced new options to make your work with commands even more productive.
To have a history available is a benefit in many environments - as a user, you may want to check what has been done already, improve upon, follow up, or repeat. In our commands pages, this information is now at your fingertips. The user-accessible time range filters have been removed, which means that the pages (with commands for Wi-Fi, UDS, J1939, etc.) now display an automatically configured history of commands; the logs are now filtered based on the first command sent in the ongoing browser session.
Two aspects are important to note:
The benefit is that users enjoy a more focused view of command logs. The interface acts more like a log terminal for the session, and if there is a need to drill down deeper into historical command logs, these are accessible on the “History” tab.
Our screenshots below show the new layout:
Commands that were recently sent are now cached in browser storage. Other than the command history, which shows browser session logs that are not limited to one user, recent commands are limited to those executed by the user who is logged in. Up to the last 5 command requests per command definition are shown. Command payloads can easily be run again by selecting them from the “Recent Requests” dropdown.
Our screenshot shows the dropdown:
The last cornerstone of our command enhancements is reruns. Command logs now show a “Run Again” button for each request. There is no more need to re-enter a lot of data: A simple click of this button will open the command form, with the corresponding payload already populated.
Our screenshot shows a log with the “Run Again” button: