Product Release Updates

Deep Connected Platform

Email Notifications

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:

Deep Logger

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.

‍
‍Benefits
‍The benefits of configurable file logging are numerous. To just state three examples, you can now:

• Reduce cellular transport costs by leveraging better compression ratios. For small files, a compression rate of about 25% can be achieved; for larger files (1 MB or more) a compression rate close to 50% is possible.
• Use existing tools by exporting files containing network data (such as CAN) to industry standard formats.
• Manage and upload files generated by other applications (such as syslogs and video files) without connecting to the device.

Deep Updater

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:

• OTA download to downstream CAN ECUs. This means that any ECU (for example, ECM, ABS, FLR) can now be updated from the ECU where Deep Updater is running.
• OTA download and install to separate HPCs.
• Human-machine interface integration to provide user consent. Deep Updater provides a mechanism to send requests to the HMI application implemented by the customer.
• Vehicle integration to check conditions for various steps of the OTA process. An example of such a condition would be that the vehicle needs to be and remain in a safe state until an update is concluded.
• Interprocess communication (IPC) hooks to handle custom installation on certain ECUs. You can write an installer to implement a custom way of running the installation, for example, for an onboard peripheral that uses vendor-specific update protocols. At the same time, the installation is still an integral part of the Sibros OTA update flow, which makes it reliable, safe and secure.
• Integration with existing installation solutions (such as an Android installer).
• Update of systems that are not directly connected to the internet. The distributed architecture of Deep Updater v3 allows its components to run on different ECUs and communicate over the vehicle network. The benefit is the support of sophisticated vehicle architectures with well-defined roles of the ECUs: safety, internet gateway, vehicle interface, etc.

Deep Commander

Command Center

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.

Command History

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: 

1. First, this history only reflects commands executed within a browser session. 
2. Second, these browser session logs are not limited to one user. If another user sends commands to the same vehicle, such logs will still show in your session logs.

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:

Recent Commands

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:

Command Reruns

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: