Are you developing a hybrid system consisting of embedded and non-embedded systems?
What is an effective approach for this?
Some thoughts on this from practice.
A common example of a hybrid system is an Embedded System that requires a Web user interface. There may also be a mobile app for monitoring and configuring the system. And finally, the embedded system is connected to a backend that runs in the cloud to collect statistical data and offer interesting services that are made possible by networking systems.
One example would be a charging station for electric vehicles that allows the user to configure and monitor the charging process via a Web user interface. Vehicle manufacturers usually want to connect charging stations that they offer themselves to their backend, for example to merge the data of the charging station and that of the vehicle. This aggregated data can then be used to map compelling functionalities for the customer and the vehicle manufacturer.
We now have a hybrid system consisting of embedded and non-embedded systems that have to be developed together. And this brings with it numerous challenges. Do you experience some of them?
When you develop a hybrid system like this, you are dealing with several development teams that live in entirely different worlds. The hardware developers of the embedded system think in development cycles (or stages) of months, the embedded software developers in weeks and the frontend/backend developers in days. It can happen quickly that the frontend/backend developers are constantly blocked because the hardware and the embedded software have not yet implemented the corresponding interfaces and functionalities.
A major risk is that the design of the software architecture, which defines the interactions between the subsystems, can only be validated quite late in the course of the project. In other words, you find out late on that there are conceptual gaps in the communication mechanisms between the systems. This often happens in non-functional areas such as asynchronous communication and timing. Which front-end developer has not been surprised that the embedded system does not respond as quickly as other backends? And a change to the software architecture in the middle of the development project quickly threatens the entire project plan, not to mention the budget.
If you also want to launch your product in a market that is new to you, it will be important to be able to show demos as early as possible, whether at trade fairs or to potential industrial customers. In such cases, it is painful to wait for the results (subsystems) of the various development teams, which then have to be integrated first because they lose potential market share to competitors.
Developing a hybrid system and capturing the market is therefore quite tricky.
But there are solutions. In the following articles, I would like to discuss effective strategies, procedures, and techniques from industry practice.
