Introduction
A trend that we may be seeing with smartphones and similar devices is that they work with various third-party sensor or controlled devices through the use of various apps written by the sensor’s or controlled-device’s vendor. A main driver for this trend has been the “There’s an App for that” mentality that has been established around the Apple iPhone with that smartphone becoming the centrepiece of most people’s lives.
Examples of this include the recently-launched Parrot “ARDrone” remote-control helicopter that uses a dedicated Wi-Fi link to an iOS device running a special app that is its controller; a barbecue thermometer being launched at the Consumer Electronics Show 2011 that uses a Bluetooth link to an iOS device that acts as a remote temperature display. There were even other examples like the Nike running-shoe pedometer that uses a dedicated wireless link to an iPod Nano running an exercise-tracking application.
These applications may be novelty ideas of implementing an iOS or Android smartphone as a SCADA (Supervisory Control and Data Acquisition) device but there will be more applications that will become more real in our lives.
Examples application fields will include:
- Food safety (thermometers that measure temperature for areas where perishable food is stored)
- Personnel health and wellbeing (blood pressure and heart-rate monitors)
- Building automation and security (dashboard apps that work with HVAC, security systems, smart meters and the like; garage door openers that work with a touchscreen smartphone)
- Automotive and marine instrumentation (engine monitoring and diagnostics)
The current situation
The main problem is that whenever an application that works with an outbourd sensor or controlled device is developed, a lot of code is added to the program to work with the sensor or controlled device. This extra “bulk” is written by the app writer usually because the writer is the one who designs the device. The communications between these device and the host smartphone or tablet is typically using USB for wired connections; Bluetooth, dedicated or network-integrated Wi-Fi for wireless connections and the application developer has to work with the link that is appropriate to the device.
If the device designer wants to build a lively application-programming environment around the device, they have to either prepare a software development kit which usually requires the distribution of a runtime module with the application. This can take up memory and can put a strain on the battery life of the device.
What can be done
An improvement to this situation that would improve the lot for device designers and application developers who write SCADA for smartphones and tablets would be to establish a “driver” model for sensor and controlled devices.
Here, the operating system could run a “driver” for the application in a similar vein to how peripherals are managed by desktop operating systems. Here, the operating system can do things like manage the polling cycle for sensors or transmission of events to controlled devices, including responding to sensors that are set to trigger software events for the device class.
This can help with conserving battery power by disconnectiong from a sensor or controlled device if the destination apps aren’t run; or sharing data between two or more apps benefiting from the same sensor data. This could benefit some platforms, most notably Android, where one can write lightweight indicator applications like “widgets”, notification-area icons or active wallpapers which just benefit from sensor data or respond to certain conditions.
The problem is that the smartphone operating systems such as iOS and Android don’t support the same kind of programmatic modularity that desktop computing has permitted due to limitations placed on them by battery-operated handheld device designs with constrained memory and storage size. This issue may have to be examined whenever a subsequent major revision of the smartphone operating system is being worked on; and could include whether a separate “driver store” is maintained at the platform’s “app store” or that drivers are supplied as “apps”. This can then allow the manufacturers to update drivers as necessary, for example to add new functionality.
Conclusion
The idea of controlling or monitoring devices from computers or mobile devices is going to becoming something more mainstream rather than just a novelty and the operating system designers may have to factor this in to their designs.
