Interfaces between low-level device drivers and algorithmic software have multiple unique issues.  These issues exist in traditional text-based development processes and in MBD workflows.  Let’s review the challenges and methods for meeting the challenges.

Hardware challenge

I decompose the hardware challenges into two categories; conceptual and technical.

Conceptual challenges

For software engineers, the concepts behind hardware interfaces are frequently a source of error.

1. Finite resolution:  Physical hardware has a finite resolution.  A 12-bit A/D converter will not provide data at a higher resolution than 12-bits.
2. Temporal non-determinism:  Readings from hardware, unless specifically configured to do so, are not assured to be from the same iteration of the algorithm.
3. Corrupted data: Data from hardware sources can be corrupted in multiple methods.  The software needs to handle these corruptions in a robust fashion.

Technical challenges

The technical challenges are standard component-to-component interface issues.

1. Data conversion: Information comes from the hardware in units of counts or encoded information.  This data needs to be converted into engineering units for use in the system.
2. Hardware/Software interface architecture:  The method for interfacing the hardware and software components requires a stricter encapsulation than software-to-software architectural components.
3. Component triggering: Hardware components can be triggered using one of three basic methods.  Schedule based triggering, event-based triggers or interrupt based triggers.

Addressing the hardware challenges

Understanding the hardware challenges we can now address them.  The conceptual challenges are addressed through education.

Conceptual challenges

1. Finite resolution: Analog-to-Digital Converter Testing
   Kent H. Lundberg (MIT)
2. Temporal non-determinism: The temporal logic of programs
3. Corrupted data: Removing spikes from signals

Technical challenges

Technical challenges are handled with education and patterns.

• Data conversion: Data conversion is done through any number of simple algorithms, from y = m*x + b equations, table look ups or polynomials.
  
• Hardware/Software interface architecture:  Interfaces to the hardware run through a Hardware Abstraction Layer (HAL).  The HAL functions can be directly called from within the Model-Based Design environment.
  
  Because the HAL is a discreet function the call to the hardware should encapsulated on a per function basis.  (Note: multiple calls can be made to the function if it is reentrant, however this tends to be less efficient)
  
  The connection and scaling of the hardware is broken into 3 sub-components shown above.
  • Access to the low level device drivers
  • Data filtering
  • Data scaling
    The top level model architecture interfaces the
• Component triggering: Hardware components can be triggered using one of three basic methods.  Schedule based triggering, event-based triggers or interrupt based triggers.  Information on how to trigger component can be found here.

Final thoughts

Well defined interfaces between hardware and software is provide clarity in communicating design intent.  The model architecture can be developed from the basic architecture proposed here, with the hardware inputs and outputs being a top level integration system.