The Device Chronicle interviews Malte Berndt, Head of Product Management, Smart Software Solutions at Dräger Safety AG & Co. KGaA.
This article follows a questions & answers-style format.
Q: Can you begin by describing the corporate make up of Dräger?
A: The company has two major parts: the medical devices area, and the industrial safety products area. Dräger Safety addresses both the private sector and public sector. In the private sector – chemical, energy (including oil & gas), steel, mining, water treatment and further segments – are addressed with its industrial safety products; fire and police departments are among the segments addressed in the public sector.
Q: What are key drivers for transformation in the industries in which Dräger operates?
A: There are two major transformational drivers across these industries: one is digitisation and the other is sustainability and these two drivers are symbiotic and supporting each other. “Digitisation should promote sustainability by creating greater efficiencies.” One of Dräger’s key targets is to increase efficiency in all processes, but there also needs to be an increase in safety through digitisation. “Many activities are running at customers in digitisation. It is hard to predict with 100% confidence which of these activities will be the real game changers. Some will fail and some will prevail.”
Q: What is the biggest technical challenge faced by Dräger?
A: The biggest technical challenge for Dräger right now is to make its devices smart in terms of communication and this includes the device interfaces. Wireless is a big topic, as is the harmonization of protocols and their definition, and lastly to find the data which has a value. Some data today is not transferred (from the devices). It is just used for pre-calculation on the devices themselves. Decisions are now being made on what data should be transferred to a central place. “This is the most exhausting work to prepare the device to be smart.” The team also started to develop software and it is a new thing to develop SaaS solutions where previously only embedded software on the hardware was the focus. On the medical side, recently acquired software skills have been used to develop an application called “Dräger Hospital Capacity Board” that can indicate how many beds are free (bed occupancy rate) at any given time in a hospital during Covid. ”Such developments were not a core competence of Dräger before but we knew how the processes in hospitals work so we used these insights and experience to build a software application to help to get the pandemic under control.”
Q: Describe a typical scenario in Industrial Safety where software updates are used?
A: The team started to develop software applications for Dräger’s test stations for gas detectors so that all data could be made available on a central cloud platform. The industrial safety products of the future are a combination of software and hardware. Not everything has to be developed from scratch: There is a strategic partnership with Microsoft Azure so components are used from there, along with other 3rd party software libraries which the team draws from. In the end, a Dräger software solution is offered to the market.
Q: Can you describe the innovative solution you offer for gas detection?
A: The part of the Dräger product portfolio I am responsible for, offers products to help with gas detection. They provide both portable and fixed gas detectors. The fixed gas detectors have been networked for several years but restricted to 4 to 20mA and just a few digital information on top. More data will be transferred going forward from these devices. The portable gas detectors have data loggers and they are starting to be equipped with wireless interfaces as there is a value in transmitting data immediately. Software solutions are developed for these products and the solutions differ from one use case to another. In one example, there is a solution to support the process of clearance measurement in a confined space. Clearance measurements must be done to avoid toxic hazards or other adverse events such as an explosive atmosphere. On the work site, concentrations are measured with the gas detectors and usually the gas testers manually document the values and relevant information and return to their office to show the results to the shift leaders. Once the confined space is released and the work permit is issued, they drive back to the site again to open the confined space and start the work. With the introduction of interfaces such as Bluetooth, the data of this process can be grabbed and put in a digitized form. A job can be started, a gas tester performs the measurement on site, documents all relevant information, and then sends the results to the office for the measurement to be approved and to get the clearance. This saves time as there is no unnecessary driving involved for the technician who is performing the measurements as well as the location can be evaluated through QR codes. Customers have indicated that there is a 50% time saving from this. And: Errors due to the manual transfer of data can be avoided.
Q: Can you describe how the more simple gas detectors are connected?
A: There are gas detectors that are simple to use and do the jobs they are designed to do. At this point of their development, they use Bluetooth and an additional gateway is needed to send the data from the devices and to manage them. The team launched an app that can connect to the Bluetooth interface and forward the data to a cloud-based solution. There are also test stations where the portable gas detectors can be inserted and need daily bump tests, the test stations are advanced, have ethernet connections, can be connected to the cloud back end, and the test stations can be used for updating the fleets. This is a good touchpoint to avoid putting another process for maintenance on top. The daily bump test can be used instead. The fixed gas detectors are networked. The major protocol is the 4-20mA output signal connection. This sends a measurement value and an error state. There is no ability to perform a software update. But with HART which is a specific protocol on top you can have a digitized way to keep 4-20mA connection to have remote access and read more information. But this is an area where approvals and certification for product safety such as those from ATEX, UL and CSA are required and this affects the communication devices also. This makes the digitisation process more complex. There are different speeds: digitisation moves more quickly than the approvals, and you can’t wait. You must develop to anticipate what approvals will come. Security is a big topic so that process systems are not disturbed.
Q: What is the role of OTA software updates in your sector and organization?
A: 15 years ago, there were nearly no updates on gas detectors. Now this is changing where these updates are done remotely, maybe on 1000s of devices in a steel mill. The updates must be done during the daily routine so the bump test in the workshop is being used as the opportunity for this now. The configuration of the gas detectors could also be done remotely. The devices are still brought into the workshops. You try to reduce it down to the level that if it needs a repair bring it to the workshop, if it just needs a software update then do it remotely.
The scale of the fleet can vary depending on the size of the customer. They can have 1000s of devices in a steel mill but there are small fire brigades that just own a few devices. The latter is more complicated as they are unlikely to have the manpower or the infrastructure to perform the updates locally. So you have to take care of both types of customers.
OTA (over-the-air) software updating of products has a benchmark from Tesla for those products upgraded in a workshop. Before Tesla, “nobody did an update of their car at home and nobody expected that a manufacturer would send an upgrade to their car over the air. It shows what is both possible and necessary even for more complex products.” A lot of companies start out with minimal viable products where the strategy is to increase the product functionality and features set later on with the customer. “This is a good thing for the customer, you do not get what is big and complicated and does not fit your needs. But the basis for success is that the software update should be uncomplicated and easy to perform. Software needs to be developed for functionality but also for cybersecurity. What today might not present a risk, might become one in 5 years. As long as we are responsible for the software we need the ability to deal with risks that might occur in the future.”
OTA software updates must also be easy as the complexity would “kill” customers with big fleets. The updates must have a predictable schedule in safety applications. They should be robust, with no crashes or failures and be a seamless part of a workflow so there are no interruptions. “There shouldn’t be an update when a user is using an instrument actively so they must be properly scheduled. It must not increase the process effort.” The customer who wants to update the instrument does not want another touchpoint to update that instrument. The test stations can be reused as a touchpoint on a daily basis to check for the latest software updates and it is only applied if the customer wants the update. Use the existing process to apply the updates. The calibration station is networked and the user has to go there every day anyway so there is no additional pain to perform the software update. Stations like this do have OS (operating systems) like Linux to perform such tasks perfectly.
We wish Malte and his colleagues well as they continue on their journey to enable industrial safety products with software and connectedness.