This article explores one major advantage XP could provide to embedded software developers: the ability to achieve meaningful progress prior to hardware availability. The article also looks at some of the difficulties of applying XP to embedded software development.

Applications that are occasionally connected have a reputation for being difficult to implement. The challenges are layered, and the heart of the problem is how data is managed. Each occasionally connected client consumes and produces data at random intervals. Islands of data are produced when disconnected, and must be reconciled later when connectivity is restored. Technologies exist to move data to and from the clients, however, only the simplest of data reconciliation tasks are handled without custom code intervening. For example, SQL Replication is a fantastic technology for moving new data from one system to another. But when a record is updated by more than one client, should the last one in always win? Also, what happens when new data entities are created on multiple clients, but they each represent the same unique entity instance? Unfortunately, data models are usually too complex to be handled by generic conflict resolution processes.

This article will discuss how to build your data model to support an occasionally connected application. The data model supports the introduction of a complex conflict resolution process built in .NET. A point-of-service sample application is introduced with steep requirements, including: Web and smart client entry points; smart clients will be occasionally connected; data entities that span multiple tables; and a complex conflict resolution process which includes support for new records that can be created on the Web application and/or smart client application instances.

This article explains how to use the architecture model to map the enhanced requirements model allocations to architecture modules.

When should an application use an embedded object database? Or, more precisely, when should a developer consider an embedded object database as an alternative to the more popular (and, probably, more familiar) relational database? This question is really two questions combined. The first is: when is it appropriate to use an ODBMS? The second is: assuming that you have determined to use an ODBMS, when is it appropriate to use an embedded one? (Many of the ODBMS systems mentioned above are available in both client/server and embedded forms.) In this article, I will deal with the individual, component questions separately. The combined answers will be the reply to the original question.

This article explores the somewhat hidden world of embedded computing and its emerging security issues. As computing power spreads into our everyday appliances and electronic devices, many principles of computer security are slow to be added to the feature list. What can we do?

This paper concerns itself with the practice and execution of using Shlaer-Mellor object-oriented analysis (OOA) on real-time control systems.

This paper reviews the open literature on general software architecture highlighting techniques applicable to the embedded domain. These areas include use of multiple views, hierarchical patterns, standard modeling, advanced documentation and application of architecture assistance tools. Applying software architecture for embedded re-use is an area identified as not being fully explored in current literature. This concept is investigated in the paper.

Thinking of distributed embedded systems (DES)—let alone the more general area of embedded computing—as a unified topic is difficult. Nevertheless, it is a vastly important topic and potentially represents a revolution in information technology (IT). DES is driven by the increasing capabilities and ever-declining costs of computing and communications devices, resulting in networked systems of embedded computers whose functional components are nearly invisible to end users. Systems have the potential to alter radically the way in which people interact with their environment by linking a range of devices and sensors that will allow information to be collected, shared, and processed in unprecedented ways.

The Internet of Things (IoT) has been generating significant hype, and the recent acquisition of Nest by Google further fanned the flames of anticipation as consumers began to imagine real-life applications. But there have also been timely reminders of the security and privacy issues associated with the growing number of connected devices (such as the Snapchat hack and the publicized Tesla vulnerabilities). In these early stages, the Internet of Things is far from secure. In this contributed article, Mark O'Neill, vice president of innovation at Axway, will provide a timely reminder of the risks presented by the emerging IoT, what enterprise IT has done in the past to overcome similar issues, and how security approaches need to change to accommodate today's level of connectivity.

Sometimes logging of an application's events is the only debugging method. The logging method's disadvantage is the large size of the code which you have to write manually to save the whole necessary information. The article touches upon the method allowing you to build a system of automatic logging of C/C++ code.