A Mock Instead of an Embedded System
Read also the introduction of this series.
When you develop a hybrid system, 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.
How can we develop such a system as smoothly as possible so that the non-embedded developers can make rapid progress?
We achieve this by having the non-embedded developers “co-develop” a mock for the embedded system. This mock replaces the embedded system and simulates the behaviour that is relevant for the non-embedded developer.
Example: Frontend for an embedded system
Let’s take the frontend, the user interface, of a charging station for electrical vehicles as an example.
Among other things, the frontend should display the charging status of an electric vehicle that is connected to a charging station (embedded system). In simple terms, the charging status can go through the following states.
Charging status
The user should also be able to control via the frontend whether a vehicle is allowed to charge or not. In the following communication diagram, this can be seen in step (3).
Communication messages between the systems
This permission to charge the vehicle is passed on by the charging station to the vehicle (4), which in turn starts the charging process (5). The charging station passes this new status on to the frontend, which indicates to the user that the vehicle is charging the battery.
Now we replace two systems with a mock, namely the charging station and the vehicle, and simulate their behaviour in this mock. So that the mock knows when it has to simulate something, we give it another interface that we can control from various development tools.
One mock replaces several partner systems
Advantages of a mock
Using the mock reduces the number of messages that are exchanged between the systems by omitting the partner systems of the charging station and only simulating the behaviour that is relevant for the frontend. In our example, the “charging allowed” message is simply omitted.
For the development of the mock, the frontend developer can choose a tech stack that they are already familiar with. In the best-case scenario, they can also use the same programming language for the mock as for their frontend.
In practice, it has proven to be a good idea to develop the mock at the same time as each user story or feature for the frontend, based on the test-driven development methodology. This way, the frontend can be developed and tested against a functional “backend”, the mock. Of course, it also makes sense to develop an automated component test against the mock. In this case, the frontend represents the component to be tested.
If the “Developer Tools” interface becomes complex, a frontend developer can develop a mini-frontend to control the mock. This mini-frontend is then used by the developer for interactive testing.
But such a mini-frontend for controlling the mock has even more advantages. It also enables other people in the development organisation to work with the frontend even before features are implemented in the embedded system.
Use cases for a mock
Translators can now look up which texts are used where in the frontend. In this way, we avoid the translators having to guess what a text label is used for in the frontend.
The marketing department can show initial product demos early in the product development process. Project managers can check features with their stakeholders at an early stage to see whether they will meet expectations, or whether there have been any misunderstandings.
The earlier misunderstandings about the product requirements are discovered, the better. If “only” the frontend needs to be corrected and not the embedded system, you save a lot of money. Changes to the embedded system usually involve several other development partners and processes, such as system testing, which is quite time-consuming.
With this approach of simulating an embedded system through a mock, we will be able to move much faster in the development of a hybrid system and avoid many expensive roadblocks. I hope I was able to give you an idea of this approach and look forward to hearing your opinion.
I would also be happy to come into your current development project and support you in eliminating problems and establishing an effective way forward. Just get in touch with me.
