A Procedure for Designing Abstract Interfaces for Device Interface Modules

1. A Procedure for Designing AbstractInterfaces for Device Interface Modules K.H. Britton, R.A. Parker, D. L. Parnas

2. The Domain & Objectives • Embedded Real-Time control system for the Navy’s A-7 Aircraft • Many special purpose hardware devices that may evolve or change over time • Goal: Design and implement device interface modules to encapsulate the control of special purpose hardware devices

3. More Objectives • The customer (Navy) wanted a system such that the hardware could evolve and the software could adapt to the new hardware • Technique: Use Device Interface Modules • Problem: If the device interface module fails to encapsulate the device details completely, device changes could result in system-wide changes • Goal: New hardware = new or updated device interface modules only • Tradeoffs: Must balance abstraction with other hard constraints such as performance requirements

4. Abstract Interface Approach Device 1 User Program Abstract Interface Device Interface Modules 1 Hardware Interface Abstract Interface n Device Interface Modules n Hardware Interface n Device n Legend: software interface hardware

5. Abstract Interface Approach Device 1 User Program Abstract Interface Device Interface Modules 1 Hardware Interface Abstract Interface n Device Interface Modules n Hardware Interface n Device n Legend: software interface hardware LocalizedChange

6. Virtual Devices System AbstractDeviceInterfaces VirtualDevice RealDevice DeviceIndependentSoftware DeviceDependentSoftware

7. Goals of Device Interface Modules (DIM) • Confining Change: Special case of information hiding – hide the hardware details • Problems • DIM’s allow user programs to exploit specific features of specific devices • Virtual device is not complete – user programs need to access the device directly • DIM’s are bloated – contain device independent code – makes the DIM hard to change • Goals • The DIM is the only component to change if the device changes • The DIM should not need to be changed if the device does not change • The DIM should be small and relatively easy to change

8. Goals of Device Interface Modules (DIM) • Simplifying the remainder of the software • Embedded software is usually difficult to understand – DIM’s abstract some of this difficulty • Enforcing disciplined use of resources • Make the DIM robust – user programs don’t have to worry about device-specific resource management • Code sharing • Eliminates duplicate code related to common operations performed on the device – without DIM’s this code may be replicated in the user modules • Efficient use of devices • User management of a device may result in unnecessary repeated operations – e.g., the DIM may cache useful device attributes

9. Example - USB • Interface consists of 4 wires – two for voltage – two for data • 128 pipes – Pipe 0 is used for setup – 127 other pipes for user devices • Hierarchical Bus architecture – 1 root controller, n-devices, and n-hubs • Fixed bandwidth – 12Mbs for USB v.1.0 Specification • Standardized connector • Common functionality • Device identification – binds OS-specific software to device (pipe 0) • Device assignment – assign the device to a specific channel/pipe • Devices communicate in any format that they wish via their drivers, the USB controller handles all of the routing, pacing, etc. • This design allows for new USB devices to be created even though the device did not exist at the time of the USB design • Support both specific USB device behavior via special USB drivers, e.g., MIDI or common USB device behavior e.g., file-system

10. Design Approach • Abstract Interface • An abstract interface represents more than one interface, focusing on the common aspects for a given device type • Designing Abstract Interfaces • Procedure based on obtaining two partially redundant descriptions of the interface • Assumptions list categorizing the Virtual Device • Programming constructs embodying the assumptions

11. Why Two Descriptions • Assumptions categorizing the virtual device is useful for discussing the requirements and determining invalid assumptions • The programming constructs define the interfaces that can be used by the user programs • Essential that the two descriptions are checked against each other to ensure consistency • Enables different constituencies to communicate with each other • The probability of the same or a similar error in both descriptions is unlikely

12. Iterative Refinement • Parnas suggests that the two descriptions should be iteratively refined • Incremental reviews and feedback are integrated into the next version of the descriptions • Parnas provides an example of important interface features missing in the first design of the ADC component – these were introduced in later versions of the abstract interfaces • Its important to get the abstract interfaces correct

13. Factoring Tradeoffs into the Design • Design goals may conflict with each other making tradeoffs necessary • Example: Small device interface modules, device-independent interface modules, efficiency. • Parnas suggestion – engineer decisions involving a design tradeoff based on considering the likelihood of future changes

14. Paper Summary • Application of abstract interfaces to make certain types of systems easier to code and easier to change • Enables software to adopt with little or no changes to different devices and support devices that have yet to be designed • Very relevant modern design objective