Embedded Application Architecture
Lately I've been reviewing some of the projects I have done in the past and wondered how we could have improved application compatibility/portability between different operating system versions and across different devices (CE devices often have custom SDKs). So I came up with the following architecture:
Figure 1 – Application Architecture
Let’s go over this architecture one layer at a time. I called the lowest level the OS/BSP Abstraction layer, this layer interfaces with the operating system (kernel and drivers); this level is used to isolate the rest of the application from any OS API changes and any device driver design changes. Device driver changes can involve a change in struct layout or change of IOCTL codes. So in its simplest form, this layer is comprised of wrapper functions that simply route a call from the application to a corresponding kernel API or driver call (think of it as a proxy pattern). In addition to simple routing, this layer can also perform some checks to make sure that the input/output parameters are valid and handle exceptions as needed. There is a performance impact by having this layer route function calls to the OS, however, the hit in performance is negligible and are outweighed by the benefits of having this layer. The advantage of having this layer is whenever there is a change in the BSP or OS, the change will only impact the OS/BSP Abstraction Layer.
The next level is the Document layer, this layer is essentially all the business logic of the application. It has hooks into the OS/BSP Abstraction layer and calls the wrapper functions to gain access to the OS and drivers. In addition, it also sends events to the View layer and handles the View’s request for data or change in state. The last layer is the View and its responsibility is to display the results from the Document layer and to handle user inputs (key presses or touchscreen taps).
Many of you may recognize the similarities between MVC (Model-View-Controller from the Smalltalk days) and the Document-View architecture. Essentially the Model component of MVC is replaced by the Document Layer and the View and Controller components are condensed into just the View Layer. Both architectures allow for the developer to swap out the user interface without making any changes to the business logic, MVC allows for some more flexibility in that you can swap out the input devices, however, it makes the architecture more complex and since the input modes for Windows Mobile/CE is standardized, I think that the View Layer can take over the responsibilities of both displaying results and taking in user input.
So by having layers we can avoid major changes to the application when the following occurs:
- Update of SDK (BSP has been modified, driver IOCTL codes or structs have been altered)
- Request for UI redesign
- Update of OS Version
- Migrating application onto a new device
Hope this helps!