During a two-day IoT hackathon, colleagues from iAV gathered at Bosch IoT Campus to get a feel for what it’s like developing an IoT solution, using Bosch IoT Suite. They had already taken part in a consulting training, but this time they wanted to see IoT in practice – not just a slide show or a cool marketing gig. They wanted something more hands-on.
As iAV's Head of Department for Software and Algorithms in the powertrain and power engineering division, it is my mission to provide innovative approaches and technologies in control design, products, system integration, and software engineering services to the automotive industry.
Elena Kurch-Lucas: You came here today with 11 colleagues from iAV. What is the motivation for this hackathon?
Daniel Heß: We’re here for three reasons. First: in our everyday work, we concentrate on developing engine management systems. Consequently, we rarely have much contact with the IoT. Nevertheless, we are all software developers and are all interested in new trends in software development. Therefore, we decided that it’s strategically important to take part in a hackathon like this. In the future, the car will also be a “thing” in the big Internet of Things. We have to be ready for that.
Second: we wanted to become acquainted with the technology. We wanted to understand how the Bosch IoT Suite works and what you can do with it. Can we use it for some of our use cases? So, we wanted to get to know the system better.
The third reason is quite simply fun. This hackathon is a nice incentive for all colleagues to get together and forget about their busy schedules; at least for two days. They are working on something technically valuable but in a fun kind of way.
What might a use case be?
Daniel: It’s about the experience and finding out how we can achieve things. We want to find out how to do remote updates, especially in our specific use case, the engine management system of a car. How can we flash software in a secure way? Nobody would like it if anybody can put new software on your engine management system. Therefore, we need a safe and reliable mechanism to update software on a device. We are here to find out more about what Bosch.IO offers in that respect.
Speaking of engine management systems: it would be great if the Electrical Control Unit (ECU) that is currently being tested on the hardware-in-the-loop test bench could fetch its data set on its own. Maybe this can be automated in such a way that it deploys automatically and is always running the latest software. No matter which part you connect, you can always be sure that it’s running the latest software. It could also be part of the test case to use a specific software version and the “thing” knows what it needs and pulls the data from somewhere. That would be the first specific use case.
- Java programming in various projects and dissertations
- Embedded software development in the automotive sector
- Full-stack web development with Meteor, React, Bootstrap, Semantic UI, etc.
- Team lead for embedded software in engine control units
- Professional scrum master
What about the hackathon itself? Which devices did you use, and how did you solve the connectivity issue?
Arthur Otitsch: We received a prototyping device – an integrated device, meaning it has connectivity and a few sensors on board. In that sense, it’s not unlike the engine controller we use for our everyday work. It’s called Octopus board, specially designed for use with Bosch IoT Suite. Then we booked Bosch IoT Suite services – Bosch IoT Hub and Bosch IoT Things – to connect the device to the cloud and access the data via an API. We used a typical IoT protocol, MQTT, to connect the device to the cloud and after that we registered the device, set up credentials and then set up permissions for the digital twin.
After that we installed a client for the MQTT protocol on the Octopus board. There, all the sensor values get collected: We had a temperature sensor, a humidity sensor, and an accelerometer. The data was sent once per second.
Then we used the MQTT connection to forward data to the Hub. The next step was to configure Things and Hub to work with each other. Some of us immediately found out that you can allow other participants to access your Things service. It doesn’t matter if it’s a user or a system, if you add it to your policy that controls access and allow it, they can access it.
How did you get in touch with Bosch.IO?
iAV is an engineering partner for the automotive industry and Bosch is a big supplier of injection systems. As hardware, we mostly use Bosch engine management systems. We have been familiar with Bosch for a long time. When we heard that Bosch was going to open the IoT Campus in Berlin, that caught our interest because we are also Berlin-based. So, we invited ourselves to the campus to learn more about what they are doing. We heard a very good presentation regarding the hackathons they are hosting and also regarding business model development and consulting services. We were impressed and decided to take advantage of at least one of these offerings. We chose Bosch because of their industrial background and their domain competence in automotive, tools, household goods etc. as opposed to other IoT cloud suppliers that have a pure software or telecommunications heritage.
How did you flash the device?
Arthur: Having accomplished the connectivity part as the basis for everything else, we touched on the topic of over-the-air firmware updates.
The Octopus board needed a server from which it could verify and to which it could report its status. The Bosch IoT Suite Rollouts service does this. It manages which connected device has which firmware in which patch set.
We configured the device, got the credentials, and put them onto the device so that the device and Bosch IoT Rollouts were able to talk to each other. The device itself then called the service at fixed intervals – in our case we chose 15 seconds, to make it easy for the participants. Each time the device asked Rollouts if there is something new. Nothing happens as long as the connection between the device and the new firmware isn’t set or configured within the Bosch IoT Rollouts. As soon as we configured that connection, the next time the device called, it got the answer that new firmware was available. The device then asked for the location of the firmware and received an URL address for the download. The third call was to download the firmware itself.
From there on, the device itself could handle its own update. Generally speaking, this results in either a success message or an error message. The device is reporting itself. In the latter case, the firmware resets to the old state. The service always has an overview of the current status of all connected devices. How many errors have there been during a rollout? Luckily, in the hackathon everybody had a success message in the end.
You then took a deep dive into gateway software. Why did you do that when the device can talk to the cloud directly?
Arthur: The first thing we learned is that there are many good reasons to use a gateway. Local or near-field protocols, like Bluetooth for example, only have a limited range of about 12 meters. This would be a physical restriction. Or you might be using a very tiny device, which does not have the capability to talk to the cloud directly. Another reason is that you can integrate a lot of logic into the gateway itself. This means you can handle quite a few operations within the gateway and reduce the amount of data you send to the cloud. It’s pre-aggregated, so we have a lot of business logic on the edge.
The base setup for the hackathon was the Bosch XDK – another prototyping device. It has a few more sensors than an Octopus board. It has a firmware on it and sends its data via UDP (User Datagram Protocol) this time, collecting all it’s sensor values. This time we had eight sensors, so we had quite a big chunk of data. The gateway device gets all the data. In this case a Raspberry Pi is running the Bosch gateway software.
What are your personal thoughts on this hackathon?
Arthur: Hacking into an IoT environment is still quite a new topic for the team. But with every hour, we got a better grasp on why it’s done the way it is done. Speaking from a software engineering point of view, the initial goal was to see what connectivity and firmware update capabilities the Bosch IoT Suite has to offer. Even though it made our heads spin, after these two days, we went home with a full bag of input and an idea of what the IoT might hold for our industry in particular.