Holistic Concept for Embedded Multifunction Display SW Specification from the Maintenance Point of View

This article provides a requisite holistic concept for embedded MFDs from the SW maintenance point of view addressing the problems of MFD symbol modification. Embedded Multifunction Displays (MFDs) show information from their parent system in form of symbols, providing clarity and user support. Especially in long-living systems such as a helicopter MFDs demand constant maintenance and adaptation. Because of the concentrated display of system activity the MFD software (SW) has to be capable of coping with MFD-specific and display-relevant system changes. Beneath there are model-based approaches defining graphical user interface (GUI) development. However no pattern can be derived for MFD SW specifications concerning how to compose display symbols. The missing pattern for symbol design does not affect the model based SW development. As long as the specification is formally described, code can be generated from it, generating the symbols on the MFD. But especially when it comes to modifying larger numbers of symbols during maintenance, the symbol specification does impact the efficiency of change processes. In addition, since MFDs are highly dependent on other systems, display relevant system changes need MFD SW modification. Therefore MFD SW maintenance has to take the embedded character into account, e.g. how changes in information of display relevant systems are adapted to the MFD symbols. In order to save time, current development models for embedded systems encourage to partition the systems into further (sub-)systems and design each of them simultaneously independent of each other. In case of MFD symbol modification caused by other systems, however, these traditional approaches make the SW maintenance rather messy and time-consuming. Therefore, a holistic approach taking account of subsystem interdependency is introduced that provides clear instruction and information on how and in which development stage SW adaptations are to be made. Two use cases demonstrate the viability of the concept.