Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

The changing landscape of embedded software devt

Posted: 13 Jun 2012 ?? ?Print Version ?Bookmark and Share

Keywords:software development? embedded systems? Service-oriented architectures?

The software development sector has transformed almost beyond recognition as it has to adjust to the rapidly changing environment it operates in. Software packages are no longer self-contained islands with few links to the outside world. Application software is not confined to the data center anymore. Devices containing embedded software are no longer standalone. Against this backdrop, traditional approaches to developing software have had to change, issuing a challenge to the application development community.

The first wall to go was inside the IT system. Service-oriented architectures achieved the critical mass needed for some of the decades-old visions of 'object-oriented' thinking to move from the fringe to the mainstream of application development. The resulting software shows at least potential for more and better re-use of functionality, and opportunities to make previously separate modules and applications work together.

Next, better network connectivity broke down the wall between embedded systems and the rest of the technology world. Today, an in-flight jet engine can report sensor readings to a service center. A medical imaging device can connect to an image processing support system. A car accessory can report real-time vehicle location data to an insurance application.

A good example illustrating the new ways of thinking software designers, architects and developers need to apply is an experimental business application which will only allow a car journey to be validated as a business trip once the driver has allowed it to set the in-car electronics to 'eco' rather than 'sport' mode.

This new environment for software means that some of the traditional assumptions that have shaped our way of thinking about software have to change. The signs are already there in travel-related applications, where pricing is no longer tied to a static price list but varies in real time, in response to customer demand.

The fundamental trend here is software behaving more and more like a control application, responding to actual, sensed conditions rather than to an abstract model of the outside world held in its database.

For example, asset management applications traditionally used to focus on scheduling inspection and maintenance. As such, they would enforce appropriate workflows for making changes, ensure documentation was updated, and apply business rules for asset valuations. All these steps were based on a person interacting with the software to review and update the underlying database. Today, maintenance engineers simply connect to an asset and read its status page. Maintenance can be scheduled according to actual, not expected, usage.

Wherever you look, you will find this sort of transition.

The value of the smart-metering revolution in electricity, gas and water depends on the capability of the meters to report more detailed, virtually real-time readings. This capability will enable utility companies to identify peaks and troughs in supply and demand as they happen, and come up with new ways of handling them. For instance, they might accord customers a lower price for electricity when charging their cars providing they agree to let the utility company use the car battery as a temporary electricity store while it is plugged in.

And of course, the use of web-interfaces means we all expect the software to work from any device, anywhere, with retained session status and offline updates available as needed.

For software development teams, all of the above means that their code will have to cope with many more unexpected conditions, situations and uses than it ever had to in the past. This will increase pressure on development teams, not least because there is a dark side to be dealt with. Every network connection, just like every data input point, represents an infiltration opportunity for malware. Software development techniques will have to build in suitable firewalls to fend off such threats. This is not an easy task when you are extending functionality across a multitude of boundaries and have to gauge the myriad potential opportunities you might be creating for malware to attack.

1???2?Next Page?Last Page

Article Comments - The changing landscape of embedded s...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top