Case Study | System PDAL

Home / SYSTEM PDAL

 
 
 

About the client

 
Fujitsu Semiconductor Embedded Solutions Austria GmbH (FEAT) is a major HMI tool provider and development partner which has been serving the automotive, industrial, communications and home entertainment markets since 1980. Their ‘right-sized’ solutions not only comprise tailored products for state-of-the-art applications and outstanding technical services, and also support through their local offices across Europe and their embedded software subsidiary (FEAT) in Linz, Austria.
 
 

Overview

 
The overall project is called Ford MFD and it is a multi-function display which provides the HMI (human machine interface) of all connected devices, Navigation included. The multi-function display is embedded in a complex CAN / LIN network structure. All controlled devices are connected to the MFD via CAN except the navigation system. The keyboard is connected to the MFD via LIN network. This LIN interfaces is visible to the SW components as additional CAN interface.
 
 

Challenge

 
The implementation need to cover the entire System PDAL software components as listed in Ford Use Case Specification. The supplier had to support the interface definition to the ExtBox components with an on-site software architect. The supplier had to consider possibilities to simulate ExtBox components and as well as the HMI GUI for component testing. Deep understanding of the interfaces and dynamic behavior of HMI GUI was required. Furthermore the vendor had to compile and link the code for the target environment.
 
 

Solution

 
The goal of the project was to develop the ‘System PDAL’ middleware which interacts with the upper HMI System and the lower ExtBox-System. Some of the PDALs were available from a predecessor project. They were used as a base for development in the MFD Nav. The existing interfaces shell was kept as far as possible and extended in order to enable the new or modified features.

The interface between ExBox application components and System PDALs shall uses an interface based on existing interface specifications between application components and HMI. An overview on the existing interfaces can be provided upon request.
 
For the System PDAL middleware the most relevant PDAL’s are:
 

  • AudioSettings_PDAL – responsible for the external Audio Settings (bass, fading, volume, DSP etc.);
  •  

  • VehicleFunction_PDAL – responsible for vehicle functionality including Parking Aid Camera (PAC), Parking Aid, Semi-Automatic Parallel Parking (SAPP), MessageCenter, Central Car, Configuration and VehicleSettings;
  • nbsp;

  • ClimateCtrl_PDAL – responsible for EATC (Electronic Aid Temperature Control) related functionality. As all PDAL components it is an abstraction layer between the GUI modelling the actual HMI look & feel and the system specific applications;
  •  

  • MediaPlayer_PDAL – responsible for media based entertainment audio functionality (i.e. Audio CD, MP3, iPod etc., but not tuner) and general media management (media eject, displaying media insertion event). This class interfaces the external media sources accessed via component MediaPlayerExtBox;
  •  

  • Misc_PDAL – responsible for miscellaneous System PDAL functionality not covered by any other System PDAL component (which all cover major function blocks). It is responsible for many minor functions which are mostly related to configuration or info, such as personalization / customization, Voice Ctrl, security functions (PIN / VIN handling (with SPM)), engineering mode (diagnosis/display tests), general settings screens (clock, illumination), and other minor miscellaneous configuration. Please notice, that functions like VehicleSettings, MessageCenter, etc. are handled in the VehicleFunction_PDAL and the AudioSettings in the AudioSettings_PDAL;
  •  

  • Phone_PDAL – responsible for the bluetooth phone and bonding functionality;
  •  

  • Tuner_PDAL – responsible for tuner audio functionality (FM, AM, DAB);
  •  

  • SPM_PDAL – serves as the main/entry point for CCA/CSFW/SPM messages (HMI has only one CCA mailbox) and HMI event messages. Other PDAL components register them self for the SEID of their related MidW-Application. The SPM_PDAL dispatches incoming information to the registered PDAL’s via functional interface;
  •  

  • InputController_PDAL – responsible for receiving any input controller events (key events via LIN or steering wheel) and forwards them to the GUI Event dispatcher. This class interfaces the VD Key application;
  •  

  • PDAL_ComponentBase – serves as a base class for all PDAL subcomponents with a generic interface that is controlled by the HMI PDAL main class SPM_PDAL. This class interfaces with the PDAL main application class.
  •  
     

    Conclusion

     
    All work on the project featured a complex team, distributed between several service providers. The HMI, ExtBox, Pdal and system integration were all handled by different teams. As the project was critical both from a deliverable and a deadline point of view the project management was delicate component. The result was an excellent integration of the PDAL subsystem with both the inferior
    and the superior levels.
     
     

    Ongoing

     
    A series of special tools for HMI design were developed up until the implementation of the project together with our customer. It included a tight collaboration between strategy, solution architecture and the development of the software application. In a highly dynamic industry like automotive constant innovation is key, and software development leads the way.