The development of control systems for complex equipment often involves the creation of suitable interfaces for the people who interact with the system in different roles, like operator, supervisor, maintenance, and possibly others. These interfaces are called HMI (Human-Machine Interface) and may have a variety of different forms, from small embedded LCD panels to large touchscreens, with the possibility of remote operation via a web browser or an app.
A very common approach is to adopt an agile approach to HMI development, in which the requirements, design, and implementation progress in a sequence of iterative, incremental, and evolutionary steps (usually called “sprints”). At each step, a cross-functional team uncovers new requirements and gets feedback on the implemented design, choosing the features to keep and those to be changed or removed. While this approach is welcomed by software engineers, it is not free from problems. First, in regulated industries it is not allowed, which is by itself a showstopper. Second, it often leads to results quite different from what initially expected, which has both good and bad side effects. In extreme (but not so rare) cases, it is a never-converging process, in which a lot of different possibilities are explored, without a clear indication of a “ready” product.
Being active in regulated industries, Fly High Engineering adopts a more linear approach, in which the bulk of the requirements is defined in the initial project phase. During the development, it happens that some of these requirements need to be rediscussed, of course. For example, this may be the case with some performance-related parameters, on which too demanding limits are initially set. With the advance of the project, it may become clear that relaxing them does not hamper the expected result and it makes life easier. Therefore, such requirements are modified accordingly. However, in all cases only a small fraction of the requirements is modified during the development, which makes the final result predictable and avoids bad surprises related to delays and extra costs to the project manager and to the client. J
Once the desired HMI design has been clarified , either internally or with the help of external experts, and the majority of requirements have been assessed as clear, unambiguous, and feasible, additional questions have to be answered before the development process can start. For example:
- How will the development team be structured and coordinated?
- How are tasks planned? How are they distributed across the team members?
- How will requirements be traced and verified?
- How will the HMI be integrated with other systems?
- How will the final solution be validated?
- What version control and collaboration tools will be employed?
During the HMI development, some critical aspects must never be overlooked. They include the long-term horizon (how will the solution be supported for the next 10 years), security risks (from user authentication and access to vulnerability to external attacks), data encryption and access (in particular to comply with regulations), and maintenance and upgrade (who can install updates, with what access, how to track them, etc.). Therefore, a significant fraction of the overall efforts is spent in the documentation and into the development of appropriate Product Configuration Management practices and tools.
User testing has to occur repeatedly during the development process. This is the most useful aspect of agile development to be incorporated into alternative approaches to project management. User testing is not only used to verify the compliance to individual requirements, but also to gain confidence that the system under development will indeed deliver the expected benefits to the user, which eventually provides the validation of the whole design. Managing user testing is therefore an important activity of the project. Tests shall be planned and specified in advance, together with the relevant metrics to evaluate the HMI effectiveness.
The last step is the deployment of the HMI to production. This has to be planned in advance of course, together with the type of documentation and training to be provided to the users. Which support structures, like helpdesk and online support, will be in place after the deployment? How will updates and maintenance be handled? What is the plan for handling issues or bugs after the product launch? Addressing all these questions right from the beginning is the best recipe to minimize the risk of our innovative project causing bad side effects!
Long-term maintenance and evolution of the HMI are also important aspects, because they contribute to the Total Cost of Ownership, which is not only the R&D investment. Actually, the spending profile of the budget over the product lifetime is an important management decision, which depends on several independent parameters, like the volume of production, maturity of the industry (i.e. tolerance for imperfect products), and financial capability of the organization. No technical project should be ever carried on before clarification and full alignment on these strategic aspects! This is why Fly High Engineering approaches each project top-down, by addressing first business and strategy related aspects to ensure that the technical work will really deliver the expected benefits.