 Hi, my name is Ryan Dushane and I'm the firmer infrastructure lead at Sibros. We provide a deep connectivity platform specializing in full vehicle OTA software updates and data logging. Today with my colleague Nick Schiffer, we're going to demonstrate our deep updater and deep logger on the Sibros Connect and Mobility Platform, powered by the ST Micro Smart Gateway Platform, or SGP for short. The SGP provides an excellent platform for OTA and data logging applications, with options to deploy software on either the SBC58 CH10M microcontroller, or the Dual Cortex A7 with Cortex M3 TC3P microprocessor. The CH10M is an ASIL D-certified microcontroller and acts as the master of in-vehicle connectivity in this system. It has direct connection to the SGP's diverse set of vehicle comms, including CAN LIN and FlexRay. It's configured with AB Flash to ensure high dependability during updates. This feature set makes it ideal for real-time, safety-critical applications requiring high dependability. Applications such as relaying data across multiple networks are performing secure ECU updates. The TC3P, on the other hand, provides the SGP with a boost in processing power, storage, and connectivity options. It can be used to run both high-level POSIX applications on the Dual Cortex A7, as well as real-time embedded applications on the Cortex M3. The TC3P can be configured to interface directly with Wi-Fi or LTE modules. It can also receive its internet connection over the integrated Ethernet switch, from a telematics unit, for example. To enable OTA in data logging, the TC3P is an ideal candidate for handling secure transmission of firmware packages and live vehicle data to the cloud. To enable our OTA in data logging solutions in the smart gateway, we'll have to deploy software components across both the TC3P microprocessor and the CH10M microcontroller. The TC3P will be running a Linux operating system and will be responsible for cloud interaction and managing non-volatile storage of packages and logs. The CH10M, on the other hand, will run FreeRTOS and will be responsible for relaying data between the TC3P and the in-vehicle networks. The SD MicroStarter Kit provides the operating systems, source code, and tool chains required to begin quickly developing on this system. All that was required to get our existing products running was to integrate the provided tool chains with our build system in a cross-compiler software. Now I'm going to hand it over to Nick to explain the demo setup we have with us today. Sure. Thanks, Ryan. So here's the hardware setup we have for the demo today. We have the ST Smart Gateway, which is running our package manager and update manager, and additionally handles our cloud connectivity between the vehicle and the cloud. These other boards you see here represent typical ECUs found in a variety of vehicles. We have our thermal controller, we have our powertrain control module, and additionally our battery management system. So today we'll be issuing a deployment down from the CBROS Cloud Portal down to this representative vehicle. And we'll see that these two ECUs, the thermal controller and battery management system, will update in parallel and then the powertrain control module will update sequentially after those. So these red LED strips are solid red for right now, which means they're in an unupdated state. When an update is deployed, we'll see that both of these two start blinking, indicating that an update is in progress. And then finally, these will transition to green here. After that is completed, we'll see the final ECU, the powertrain control module, go through the same sequence on its own. And additionally, we'll be able to view detailed information of this update sequence on the CBROS Cloud Portal. Okay, here we are on the CBROS Cloud Portal. We've created a vehicle here to be associated to our hardware setup to my right. And what we're going to do now is deploy a firmware update package to our vehicle here. So what I can do now is go to our packages page. This is one way to deploy down to a vehicle. We also have rollouts functionality. But for the sake of demonstration, we're going to do an individual deployment. So I can go here to packages and select the package I want to deploy. So that'll be DevCon package one version 34. And I will deploy that here. And then once I confirm this, we'll see on the hardware and in the portal that an update will proceed. As described before, our thermal controller here and our battery management system here are updating in parallel. So these two are updating at the same time over the same bus. Then these will continue to blink until they're both complete, at which points these will transition to a solid green color here. After those two are completed, the final power train control module will go through the same sequence on its own. And this is all being choreographed here by the ST Smart Gateway. So that's, again, running our package manager and update manager components. And so the cloud is interfacing with the package manager, which then streams the update through the update manager. Because the update manager normally runs on an embedded target, it doesn't necessarily have the space or resources to hold the package itself. So it's streamed via the package manager, which generally will run on a POSIX system. So we'll give the power train control module here a few more seconds to complete. And then we can look at the portal. So here on the portal, we can see that all three ECUs have finished updating. And these match what are shown on the board, our thermal controller, battery management system, and power train control module. And if we expand any of these, we can see some information about this component. So in this case, we updated the application on these ECUs. I can also update the Boo loader, the calibration block, et cetera. And we can see there was previously no application version on there. And then now we have this version. And if we expand further the app section here, we can go through and view all of the detailed UDS information. So these logs are all pertinent to this specific app on this specific ECU. And we can see that this is updating the BMS app hex. And we can see the update manager state information. We can see UDS information, et cetera. So if there was a fault here, we would see it both at the deployment level, vehicle level, and at the ECU and image level. So we can scrub through here and see what exactly went wrong. In this case, they were all successful. So we don't have any errors here. And we can look at the states that went through to get to this point. And the same can be said for these other ECUs. We have our applications for both of these with different versions. And we can see that our update has been successful, both from the portal and from the LED lights on our hardware. For the second half of the demo, we're going to be talking about the deep logger. The deep logger enables live vehicle analytics using your existing hardware rather than requiring additional inexpensive third party hardware. Starting from the deep logger's overview page, we can see information about what's going on in the system where it's deployed. We can see CPU usage, how many can frames are being transmitted per second. Historic data as well, such as how many can frames have been transmitted and how many log lights have been transmitted since the system was started eight minutes ago. We're also given information about bus load. In my case, I only have one bus configured, which we can see is sitting in about three to 5% load. With the deep logger, there are generally two different ways you can consume its data. The deep logger is leaving comprehensive and high resolution log files on the device itself containing every signal present on the vehicle's communication buses. These logs are then later compressed and transmitted to the cloud where they can be downloaded by the user and consumed in traditional tools offline, such as vector tools. Additionally, the deep logger does do live logging. This live data can be viewed in the Sibros cloud but can also be used via API for third party use such as machine learning for predictive maintenance. The data that's being sent by the deep logger is fully configurable by the user to work around bandwidth constraints that may be present in the vehicle. I can choose a subset of signals from the DBC and I can decide at what rate I'd like these signals to be sent to the cloud. These live signals can be consumed a few different ways in the Sibros portal. We'll start from the dashboards page. The dashboards page gives you a few different panels which are collections of signals within different domains in the vehicle. So for example, the powertrain panel is going to show us information such as state of charge, cell temperature, motor temperature, speed and cell voltages. The user is able to move any of these plots around. They can be resized if needed. And they can be edited. These plots are fully interactive, allowing you to zoom in on a subset of signals and cross correlate different signals at different points in time. The user is also given their own personal plot page where they can configure their own widgets. You can see I've already configured a widget that plots the BMS state of charge against state of health. So let's open the edit button and see how I did that. So you can essentially add signals that are present in the DBC. You can of course choose different colors for these signals if you'd like and give them nicknames. And you can also choose from a different method, a few different methods of visualization. The default is going to be a graph view. I could also just show these simply in text form, or as a progress bar. So for example, let's say we would like these to rather be a progress bar. I'll go ahead and change the visualization method, save it. And we can see our changes. And note you can also change the time frame that any of these widgets are displaying. Right now I'm just looking at the last five minutes. I could if I wanted to look at the last 15 minutes of data, so on and so forth. Lastly, you can simply just view the live signals in table view. Any signals which are configured to be transmitted as we saw in the configuration page will be present here. Some of these signals are not available, of course, because I've not yet configured the debugger to transmit them. That brings us to the end of this demo. We covered a lot. So if you have questions or would like to learn more about the Cibro Steep connectivity platform on SGP, visit our website at cibros.tech or email us at info at cibros.tech. And we'd be happy to set some time up with you.