Contemporary embedded systems in the network and communications infrastructure frequently use service groups, containing redundant components, to achieve high, or carrier grade, availability levels.

System attributes such as component state, service group membership, action taken upon component failure, and component operating parameters are often controlled by software known as Service Availability middleware. The Service Availability Forum is dedicated to creating and promoting its open service availability specifications for quickly and cost-effectively building carrier-grade equipment and applications.

Consider the example of an active/standby service group. Board A's database application is active (providing service), while the standby application on board B is ready to take over should board A or its application fail - this takeover process is known as failover.

With properly designed checkpointing (duplication) of state data from the active to standby application, clients of the database might experience a short database service loss during failover but no loss of transactions or data.

To expedite detection of active and standby database application failures, the Service Availability middleware periodically sends requests for a health check or heartbeat. A received reply indicates that the application is healthy.

Embedded systems sometimes employ the architecture of a service group to achieve high availability levels. Board A is running a database application currently providing service while board B stands by to provide backup if A fails. The process is called failover, which offers a guarantee of no data loss even though there might be a short interruption in service. Source: Motorola

The board resource control software handles platform resource-centric details, such as board power control, informing Service Availability middleware of board presence, type, and capabilities; originating events for abnormal conditions, such as an out of tolerance board temperature sensor; and accepting board control data from the middleware.

Examples of data passed over the application interface include: Application role (active, standby, or unassigned), heartbeat requests and replies, data relating to checkpointing, as well as indications of errors and other events experienced by the application. The platform interface passes data associated with platform and hardware resources, which includes: board or component power state, presence and nature of hardware resources, control and sensor data, as well as hardware events.

Consider the high-level commands, from Service Availability middleware to applications and board resource control software, needed to set up the sample active/standby service group.

During routine operations, the middleware exchanges heartbeat requests and replies with the database applications via the application interface. Checkpoint data is typically sent directly from the active to standby application over a logical connection arranged through the application interface.

Should the active database application fail, its absence might be detected by a failed heartbeat exchange.

Interface management

Besides the application and platform interfaces, a system management application could interact with the middleware through a management interface. The management application may receive instructions from an operations center via SNMP, for example, to swap the roles of the active and standby database applications. The management application would forward these directives to the middleware, which would in turn effect the changes via appropriate commands on the application interfaces.

Besides an active/standby high availability redundancy scheme, the interfaces could be used to enable other service group types, such as:

* Active/Active (Load Sharing): All members of the service group are actively providing service. System power supply service groups often operate in this mode.

* N+M: "N" members of the service group actively provide service, while "M" members are in standby, ready to take over upon failure of any of the active members.

The material presented so far shows the indispensability of the application and platform management interfaces in providing the control needed for 5NINES or carrier grade availability.

Today's typical Service Availability middleware implements these interfaces in proprietary fashion, resulting in non-portability of application, platform and management software to other middleware environments. Moving this software across platforms, or diverse middleware on the same platform, requires software recoding to a new set of interfaces and usage rules.

The Service Availability Forum (www.saforum.org) is currently developing standardized interface specifications for carrier grade application and hardware platform interfaces.

The first specifications, targeted for the hardware platform areas, are scheduled for release by year-end 2002, with application interfaces to follow. These interfaces will enable embedded developers to produce high availability applications more efficiently by:

* Lowering development costs: An embedded developer can use resources to develop quality applications that support higher availability levels, rather than consuming these resources in applications porting.

* Shortening time to market: Applications can be developed for a diverse range of platforms in a shorter timeframe.

Achievement of carrier grade availability in a computer system, designed for the networking or telecommunications markets, requires an effective set of interfaces between the system's Service Availability middleware and application software, platform software, and management applications. Standardization of these interfaces enables the embedded developer to produce high availability applications, for a diverse range of networking and telecommunications platforms, in the short timeframes required by today's marketing environment