NEST Architectural Overview

Articles and Tips: article

MARY HILL
Director of Developer Relations
Extended Networks Division

01 Nov 1994

Introduction
What are Embedded Systems?
NEST Architecture
NEST Components
NEST Software Developer's Kit (SDK)
Implementing NEST
How a NEST System Works
Possibilities with NEST
Conclusion

Introduction

The past decade has witnessed an explosion in the use of PCs, resulting in the increased proliferation and use of networking as a key computing technology. As recently as five years ago, nine out of every ten PCs operated as standalone workstations; today, the tendency is to network all machines in use in the workplace (The Economist, Sept 17, 1994, "The Computer Industry Survey," pg. 5 [following pg. 60]). In the United States alone, 30 million PCs are now wired into such networks; the world-wide percentage of the total population of 176 million PCs that is networked continues to grow daily.

There's more to networks than just PCs communicating with one another, or with other computers that provide network services. The same tendency that has propelled the growth of networking for PCs applies increasingly to other systems as well: In the workplace, it's commonplace to find printers, fax machines, scanners, and other kinds of devices attached to the network in some form or fashion.

In traditional manufacturing environments like the factory floor, networking has long served a role as a data highway for real-time control and automation information as well. These applications include all kinds of devices ranging from fabrication equipment, packing or routing equipment, a variety of robots used in assembly lines, and automated controls of all kinds in process-oriented environments.

In the past, such control networks have been segregated from workplace computer data networks.

But "just-in-time" parts deliveries, improved production and design tools, and a need for tighter control over manufacturing have pushed such operations to consolidate data and control networks for better information access and data-sharing.

Then too, the biggest future market for computers and networking, according to many analysts, is at home, not at work. As PC prices have tumbled, sales of home computers for education and entertainment have exploded, especially in the United States, where one third of all homes now have PCs. Link Resources, a New York based market research firm, estimates that the population of home computers will increase by 17% annually over the next five years, as opposed to the more modest 8% growth they forecast for the corporate market.

In fact, they believe that by the end of decade, over half (54%) of the world's PCs will be in the hands of consumers, not business people, up from 34% in the mid 1980's. Because of its focus on "edutainment," this market will propel the need for access to public and private information providers for everything from video on demand, to information warehouses of many varieties (video, audio, programming, etc.), to home control systems of all kinds.

What all of these marketplaces have in common is a need for computers and other types of hardware to be able to interact with one another -- typically, by using a network. In the workplace (and, to a certain extent, in the home) this means being able to access all kinds of shared devices like printers, copiers, telephone and voicemail systems, fax machines, scanners, etc., using the network and one's desktop PC. In the factory, it means being able to operate and monitor production facilities through data and control networks already in place.

For the home, it also means being able to reach outside one's domicile, be it by telephone, cable TV hook-up, or some other means of real-time communication, to obtain a rich variety of educational, informational, and entertainment data for use on one's PC, television set, game player, or other interactive equipment.

Within the home (and to an extent, in the office and factory as well) it also means being able to connect with and control appliances, heating and air conditioning systems, lighting, and other systems commonly in use in the surrounding environment.

What are Embedded Systems?

The key to all of these needs is in technology that's often referred to as "embedded systems." As the name implies, this technology relies on some kind of built-in computing and communications capability inside devices designed primarily to fulfill specialized roles. While it's hard to limit the range of what kinds of systems this could cover, the key ingredient that all of them possess is some kind of built-in microprocessor or equivalent computing intelligence, along with methods for issuing commands to and obtaining data from the microprocessor on an intermittent or ongoing basis.

Concrete examples include many items common in daily life. Most automobiles incorporate a handful of processors that control key subsystems ranging from brakes (ABS braking systems), to fuel ignition and engine controls (many vehicles today use computerized fuel injected systems rather than old-fashioned carburetors), to suspension and ride controls (many vehicles offer "dial-a-ride" suspension tuning that let the operator vary the suspension's characteristics with the turn of a knob), to temperature controls and audio for the passenger compartment.

Likewise, most thermostats and climate controls include microprocessors that can be programmed for separate day and night settings, weekend settings, or climate range controls. Many large office buildings network their individual thermostats together and use computers for overall control, in an effort to contain rising utility costs.

What's been missing from many embedded systems has been a key ingredient -- namely, networking. Networking is vital because it enables embedded systems to receive ongoing instructions from external sources, rather than forcing them to rely on static, pre-defined programming. Networking is also valuable because it lets embedded systems communicate about their status, health, and operating conditions to other systems, that can then act quickly and efficiently on the basis of such information. By supplying key technologies to bring networking to embedded systems, Novell offers software and hardware developers the keys to bridge these two crucial markets.

Novell Embedded Systems Technology (NEST)

To facilitate the connection of intelligent devices to networks, Novell has developed NEST. NEST defines a systems architecture, and supplies a set of implementation tools and strategies, to add value to embedded systems by making NetWare services available for their use. Because these services range from file and print, to communications with other network nodes, to comprehensive networking protocols for queuing, time synchronization, device and network management, and data exchange of all kinds, they can greatly increase the capability of embedded systems, while allowing them to communicate much more freely.

Because Novell recognizes that the bulk of embedded systems uses proprietary runtime environments, rather than standard computer operating systems -- the ratio is 80% proprietary, 20% standard, according to Novell's own research -- NEST has been specifically constructed to accommodate all kinds of processors and software environments. NEST supplies portable networking protocols and network services packaged as software source code modules that developers can easily integrate with their embedded system software. This modular design lets developers select only those protocols and services that they actually need, without forcing incorporation of unwanted components.

Likewise, the NEST components have been constructed to be both compact and robust, based on an understanding of the stringent cost controls necessary in most embedded systems. For that reason, developers can choose from a number of protocols and services, to best fit their particular systems' needs.

Fundamentally, NEST is a technology that lets developers leverage Novell's extensive knowledge in networking, to make it quick and easy for them to connect their embedded systems to computer networks. NEST both simplifies the underlying network complexity, and makes network access transparent to developers and users of intelligent devices. NEST extends the capability of such systems with a minimal increase in unit cost, development effort, and ease of use.

NEST Architecture

NEST is designed to meet the exacting needs of embedded system developers, for whom code size, resource requirements, and CPU overhead are paramount concerns. In other words, NEST has been constructed to a set of design criteria that recognize that networking is an ancillary function for embedded systems whose primary function -- be it climate control, printing, or controlling a vehicle's brakes -- must be delivered without any impairment or additional delay.

NEST Design Criteria

On the basis of these concerns, NEST's design criteria include the following:

Modularity. NEST is built around a modular, layered design that permits selection of only those elements required to implement a particular specification. This makes the resulting code as compact as possible, and helps control costs and software complexity.
Portability. NEST modules are written in ANSI-compliant C, and its source code is designed to minimize and isolate processor dependencies. NEST code is portable to virtually any processor, allowing developers the freedom to choose the best possible platforms.
OS Independence. NEST is operating system neutral, and can run in most embedded system runtime environments. Byte order issues, type definitions, and other code idiosyncrasies are masked within NEST, leaving developers free to work with whatever operating system or runtime environment best suits their embedded systems.
Network medium independence. In keeping with Novell's medium independence, NEST minimizes and isolates network hardware dependencies to accommodate a broad variety of LAN interface hardware and topologies.
Open architecture. NEST is built on an open architecture, around widely available APIs, for maximum flexibility for developers to provide enhancements and future extensions. NEST makes it easy for developers to add value, yet still retain ready network access.
Comprehensive services. NEST delivers the many NetWare services already available to desktop systems like PCs, Macs, and workstations, to embedded systems developers and users.
Reliability. NEST code is based on mature, 9th generation NetWare code with over a decade of field proven reliability. Novell also provides test tools and certification services to NEST developers to enable them to guarantee that their devices and services are NetWare-compatible.
ROMability. Because embedded systems often do not include secondary storage (like disk), NEST code is designed for execution from ROM and for downloading from a server (for EPROM applications).

NEST's Client/Server Heritage

Because NEST's networking capabilities are firmly based in NetWare technology, it is important to understand NetWare's client/server architecture. In this approach, the network and services are managed through a central resource called a server. NetWare has achieved its market preeminence as a server because of its file and print sharing capabilities, because of its support for heterogeneous networks and services, and because it supplies a comprehensive set of directory services for managing access to and for monitoring network resources.

NetWare services are available to client applications through Application Programmer Interfaces and network protocols that transfer requests for service from the client to the server, and which then return a response from the server to the client. At present, there are over 800 distinct API calls supported for the NetWare environment, spanning a range of services from file and print, to directory, database, management, and communications of all kinds.

NetWare also provides transport level services for peer-to-peer connection-based and connectionless communications between processes on different network nodes. Such services do not require a dedicated server, and in fact let network nodes freely adopt the role of both client and server as their communication needs dictate. The difference between connection-based and connectionless services hinges on reliable delivery: connection-based services permit the communicating nodes to verify the success or failure of their communications; connectionless services require that the applications that use them be able to respond appropriately should communications between sender and receiver fail.

NEST provides access to both client/server and peer-to-peer capabilities and services for embedded systems, so developers can utilize the kinds of functionality they need to leverage access to the network. In the next section, we examine the layered components that comprise the NEST architecture.

NEST Components

As Figure 1 illustrates, the NEST architecture consists of three distinct layers: the Connectivity layer, the NetWare Services layer, and the Application layer. These layers rely on the presence of an operating system (or runtime environment) that will be described later.

Figure 1: This shows the NEST architecture layers.

Connectivity Layer

The Connectivity layer includes the protocol stacks and the underlying networking technology that moves packets between nodes. It provides the connection between the NetWare services layer and the physical network. Through an API, this layer also provides peer-to-peer transport-level communications services to applications.

The connectivity layer is further subdivided for integration of network transport services with an embedded system's lower-level hardware drivers. The architecture for this layer is based on the Open Data-Link Interface (ODI) model that Novell uses as its basic network driver technology, as shown in Figure 2. ODI facilitates the use of multiple protocol stacks in a single system without the overhead and complexity of streams-type implementations. ODI also facilitates development of network drivers by isolating hardware-dependent codes to a single set of modules.

Figure 2: This shows the ODI network driver model.

ODI is subdivided into two layers, called the Link Support Layer (LSL), which handles the communication between the protocol stacks and the Multiple Link Interface Drivers (MLIDs), which supply the low-level physical interface drivers necessary to communicate with one type of networking technology or another (i.e., Ethernet, Token-Ring, AppleTalk, or ISDN as shown in Figure 2).

The ODI model also allows a single networking technology to support multiple protocol stacks simultaneously, so that a single Ethernet interface could accommodate IPX, TCP/IP and AppleTalk.

When an incoming packet arrives, the LSL determines the protocol stack that should handle it. Then it's up to the stack to decide what should be done with the packet, or where it should be directed. For outgoing traffic, the stack hands a packet off to the LSL, which in turn routes it to the appropriate MLID. The LSL also tracks which protocols and MLIDs are currently loaded, and manages location and use of the modules that are loaded.

MLIDs act to connect the LSL to a LAN interface, which can reside on a separate network interface card or as part of the embedded system's circuitry. MLIDs are device drivers that handle sending and receiving packets to and from a particular physical connection.

NEST simplifies the task of LAN driver development by stratifying the MLID to address media, topology, and hardware issues separately, and includes predefined modules for common media and topologies.

The modules that make up the NEST MLID are as follows:

C Language Media Support Module (CMSM) contains general functions common to all interface drivers.
C Language Topology Specific Modules (CTSMs) manage the operations specific to a particular topology, like Ethernet, Token-Ring,or FDDI. Support for multiple frame types is supported in allthe CTSMs so that all frame types for a given topology are supported.
C Language Hardware Specific Modules (CHSM) handles all interactions with the network interface hardware. The primary functions of the CHSM include hardware initialization, reset, and shutdown, and packet reception and transmission. This code acts as a template that can be easily customized for the specific hardware in use.

NetWare Services Layer

The NetWare Services layer provides access to the wealth of services available to client systems from the NetWare environment. This collection comprises over 700 NetWare services, including queuing, bindery and directory services, connection, file and print, messaging, auditing, synchronization, and authentication services. An embedded system application might use NetWare services to log-on to a NetWare server, to open a file, read that file, and then close it. Such applications could also use bindery or directory services to look up an object on a server, either to locate or access it.

To minimize size, these services are provided as a collection of source libraries. Only those services actually used need to be included in any given application, so services not used will be omitted from the run-time code when the application is built. Consequently, embedded systems have access to comprehensive services with minimal impact on system size.

Application Layer

The Application layer contains the application programs that control the operation of an embedded system -- this is the code that actually lets the system perform its appointed tasks. Using NEST, such applications can request services through the NetWare client API libraries, or by calling transport-level services directly, through another API. The application layer is open to Original Equipment Manufacturers (OEMs) and Independent Software Vendors (ISVs) to develop their own applications. Ultimately, the developers who build the applications that run at this layer will decide when and if to use NEST APIs for network access.

Operating System Interface

NEST software relies on an underlying operating system to provide basic services to applications. These include memory management, task switching, synchronization, and timers. To ease porting, Novell has specified all required system-level functions in a simple API for implementation on the embedded system's kernel, runtime environment, or operating system.

This API is called the Portable Operating System Extension (POSE), and defines all the operating system services required by NEST. These functions are derived from the POSIX 1003.x standards, and POSE functions have been carefully selected to provide services common to most embedded systems while minimizing space and overhead. Thus, a crucial step in using NEST on any embedded system is to complete the mapping of the POSE API to the target system's specific call interface and services.

Data Flow Through the Layers

NetWare services are accessed by embedded applications through the NetWare client API libraries. A client application requests a service, such as "open file" or "write to a queue," so that function will be linked into the program at build time. At runtime, the NEST requester builds a packet, adds the packet signature and provides RSA authentication services to the packet to ensure system security. Then, the NEST requester sends the application's request to the appropriate NetWare server through the protocol stack, through the ODI driver, and out onto the network. The server then executes the requested function and returns its response, which traverses the driver, stack, and application in reverse order.

Applications that don't require NetWare services can write directly to the protocol stack. Thus, an application that simply needs to establish a connection to another node, or wishes to broadcast messages to a number of nodes, could use the transport level services provided by most stacks (for example, IPX/SPX and TCP/IP).

When the protocol stack receives a package of data from the NetWare services layer or a request from an application, it handles any fragmentation or disassembly that may be required to match a logical message to the requirements of the underlying physical medium. The resulting packets are delivered to the LSL, which routes the packet to the appropriate MLID, which in turn handles any topology-specific information. The result is that protocol stacks are effectively medium- and frame-type independent.

This flow reverses when an embedded system receives a packet. The lowest layer of the MLID reads the packet from the wire, discards the MAC header (if present) and forwards the remainder to the LSL. The LSL routes the packet to the appropriate protocol stack, which removes the header after extracting the necessary information, and handles defragmentation and reassembly as needed. Then the stack hands the data to the appropriate application or service.

Error checking occurs at several levels in the process, so applications are assured that all information is accurately transmitted, and that information received is reliable.

NEST Software Developer's Kit (SDK)

NEST products and services are delivered to developers in the form of the NEST SDK, which includes client software for NetWare 3.12 and 4.x environments, providing support for the latest NetWare services like directory, enhanced security, and protocol enhancements. The SDK offers a variety of source code modules, software validation tools and documentation to assist in connecting embedded systems to NetWare networks.

The NEST SDK consists of the following software.

C Source Modules

This includes client software to connect an embedded system to a NetWare network. The NEST SDK provides C source from all layers of the NEST architecture, including an IPX/SPX protocol stack with LSL and MLID source for the NE2000 Ethernet network interface. It also includes API libraries for NetWare services (NWCALLS), authentication (NWABT), directory services (NWNET) and localization services (NWLOCALE). The service layer also includes the NEST requester, which manages packet construction for IPX/SPX and invokes packet signature and authentication services. All APIs are provided in library form so functions can be individually selected and linked to embedded system applications for minimal overhead.

Applications

The SDK includes two applications: Embedded PSERVER (EPS) and Embedded NPRINTER (ENP). EPS essentially lets a printer function as a standalone print server, and ENP lets a printer accept print jobs from other print servers, either based on EPS or the NetWare PSERVER NLM. Printer manufacturers can embed these applications in their printers to support direct connection of printers to the network, which will then be compatible with existing NetWare printing and management utilities. Other embedded system developers can study the source for these applications as a valuable learning tool.

POSE Interface Specification

This supplies a thorough definition of the OS functions required by NEST, which range from memory management, process creation, time and synchronization services, and semaphore and privilege management. The most important initial step of a NEST implementation will be to map these functions to their actual implementations on the target processor and software.

Testing Tools

There are three software validation tools included with the NEST SDK to ensure correct implementation.

These include the following:

The Novell Protocol Test Tool (NPTT) for validation of the IPX/SPX implementation
The Print Signature Test Tool (PSTT) for validation of the implementations of EPS and ENP
The Remote Printer Test Tool (RPTT) to test remote printer modules in embedded systems.

These are the same tests used in the Yes certification process, so once an implementation passes these tests in-house, Novell certification should be just a formality.

Documentation

The NEST SDK includes a comprehensive set of 7 manuals that cover everything from a set of general developer's guidelines to C language coverage of driver development, client APIs, application porting, programming style guides, and an overview of the testing and certification process. In short, all of the tools and interfaces are covered, to assist developers in learning and using the SDK.

The purchase price of the NEST SDK also includes training, distribution licenses for pilot testing and commercial development, technical support, and a credit that can be applied to Novell Yes program certification for resulting embedded systems.

Implementing NEST

When building an embedded system using NEST, Novell suggests the following general sequence of steps:

Scope the effort. This consists of setting the network objectives for a project, to determine the level and type of networking the embedded system requires. If, for example, an embedded system must interact with a NetWare server, this would require inclusion of the NEST requester and services from the client API libraries. If the system simply needs to broadcast occasional status information or data, only the IPX protocol stack would be necessary.

The output of this stage should be a specification for the networking activities desired, and a list of the related NEST modules which must be used to implement them. It will also be necessary to select an operating system or runtime environment at this point. NEST requires a multitasking operating system with a preemptive dispatcher. Once the OS is selected, the POSE function library must be constructed (Novell is working with numerous OS vendors to assist them with construction of the POSE library for their environments).
Set up the development environment. Because NEST software is written in ANSI C, it is portable to any ANSI-compliant C compiler with corresponding runtime libraries. Header files are provided to ensure portability across CPUs (with differing word sizes from 8 to 16 to 32 bits) but must be adjusted for their target environments. The delivery mechanism for code diskettes assumes that DOS files in hierarchical directories are acceptable, so some translation and migration may also be required to move these files.

Software built procedures for NEST code follow the PVCS Configuration Builder, which is currently available for a variety of platforms. This product is very MAKE-like so its build scripts can be easily ported to other build tools. The test tools require a workstation running MS-Windows for execution.
Write a POSE Layer for the EmbeddedOS. Once the effort has been scoped, and the development environment settled, the first task should be to build the POSE interface to the target operating system. The NEST SDK includes documentation covering function names and parameters passed to the OS, and the resulting return codes. Writing the POSE layer requires developing and verifying the run-time library that maps these functions into native operating system services.

Using an OS that supports the POSIX1003.1, 1003.4, and 1003.4A specifications will simplify the effort, because these specifications drove POSE development. Novell therefore recommends that developers use an operating system with these characteristics whenever possible.
Write the LAN Driver Interface to the Network Hardware. The NEST protocol stack is designed for the ODI driver specification. The MLID is the portion of ODI thatmanages the logical-to-physical LAN interface, so this will need to be adapted to the chosen LAN interface hardware. But of the three MLID layers, only the CHSM layer is hardware-specific, which should further ease the porting process. The other two layers, CTSM and CMSM, can be integrated by simply compiling them for the target system.

The protocol stack should be implemented bottom-up, by starting at the CHSM and adapting it to the targethardware, then adding CTSM and CMSM layers, and finally adding the LSL and IPX/SPX protocol stack. The test software provided in the SDK will indicate whether or not the driver interface has been properly implemented.
Port the NEST Services Layer. The NEST service layer must be ported next, if the embedded system application requires NetWare services. This includes the client API libraries, and the NEST requester. Porting these elements usually means compiling them for the target system as libraries.Because many of these functions make POSE calls, this will also thoroughly exercise the POSE Layer of the NEST implementation as well.
Develop the applications. With the POSE Layer and the LAN interface complete, the infrastructure is ready for an embedded application. Because such programs derive from the functionality required by the target embedded systems, they will vary widely from one to another. Because NEST handles network connectivity and delivers a comprehensive set of network services, developers can build their applications without having to tackle the complexities of network software development. This should simplify the overall development task, and let developers concentrate on the specifics of the target embedded system's application.

Once an application is complete, it should undergo thorough alpha testing before moving on to pilot testing outside the development company's confines. This is an excellent time to complete the various test regimes using the certification tools supplied with the NEST SDK.
Perform pilot testing. With a complete implementation, it's time to begin pilot testing at selected sites. The NEST SDK includes licenses for up to 25 such sites (if more are needed, please contact your Novell sales representative).This is the time at which features and functions get their reality checks, and provides a final opportunity to adjust the embedded system's capabilities before going into commercial production. Therefore, the importance of the pilot test phase cannot be overstated.
Obtain Novell Certification. The final hurdle before commercial release is the Novell Certification process, conducted by Novell Labs to ensure that devices and services are truly NetWare ready. Once products have been certified, vendors can display the "Yes" logo on product packages. Because Novell Labs will use the same tests on embedded systems as included with the NEST SDK, such testing should be largely a formality, provided that developers successfully complete the test suite in-house before submission for certification.

How a NEST System Works

In this section we take a brief look at what including NEST, and network access, in an intelligent device will mean to network administrators and to end users. Our discussion assumes that an embedded system with NEST capability shows up at a network administrator's door, and takes it from there. For the sake of a concrete example, we assume it's a NEST-based device that offers both fax and print services.

Installation

For most NEST-based devices, hardware setup will remain largely the same, except for connection to a network. NEST's ability to reside in ROM will often mean that NEST-equipped devices function in a "plug and work" mode -- that is, users can get right to work using the device as soon as it's set up and plugged into the network.

Because our example involves both fax and print services, we must assume that either ENP or EPS capabilities are present; for the sake of simplicity, we assume its EPS. In that case, the network administrator would consult the device's manual and attach to the device over the network, for the purpose of configuring print and fax service queues, for supplying user account information and privilege levels for authorized print users, and for supplying account and e-mail address information for authorized fax users. Most likely, this would occur on the administrator's PC workstation, using either a DOS or Windows installation and configuration utility.

For some users (e.g., Windows or Macintosh clients), it may then be necessary to install driver software for the new device on those workstations. Savvy administrators can take advantage of software distribution tools, if available, or use the WS_UPDATE tool included with NetWare, if appropriate.

Once installed at the client and server ends, the administrator could then advertise the presence of the device to his or her intended audience. We'd also recommend supplying information about special functions and features of the device, with perhaps a macro or batch file to disguise the use of complex parameters or settings when appropriate.

Manageability and Use

The real power of NEST comes into play once a NEST-equipped device becomes part of the network. In general, such devices will be manageable through conventional NetWare tools, including in our case the various NetWare print consoles, bindery or directory services, and the NetWare console or administrative utilities. In our example, it's even possible for the vendor to create a special management NLM, or perhaps even a "snap-in" application for the NetWare Management Services (console). Whatever the actual details of the implementation, the important thing is that NEST-equipped devices will appear on network maps as manageable devices, and will be remotely manageable using standard NetWare management tools.

For users, NEST-equipped devices appear in their resource information under NDS, or can be accessed as standard print devices (or servers) using NetWare 3.x technology. This makes them behave like familiar network devices, which can be managed using familiar tools and utilities, and which will often appear simply as extensions to their local desktop machines, rather than as arcane and unapproachable mystery devices somewhere "out there" on the network. This is the ultimate value of NEST: that it takes intelligent devices of all kinds and makes them part of a familiar and widely used networking environment.

Possibilities with NEST

Much like the explosion of PCs in the 1980s, there's an explosion of intelligent devices occurring in the 1990s. These devices, which range from copiers, fax machines, security systems, and factory robotics to video recorders, television sets, telephones, and automobiles gain their intelligence from the presence of embedded systems that consist of operating system and application software. It's NEST's job to make those systems part of a broader networked environment, and to facilitate their ability to exchange information, receive instructions, and respond to remote control, in a communications-rich environment.

With NEST, intelligent devices are able to share information and resources not only with one another, but also with computers on wide and local area networks. NEST opens up a world of possibilities that seemed only science fiction a few years ago.

Already, vendors with interests in the following marketplaces have licensed NEST technology from Novell:

Networking devices (network interfaces, remote connectivity, routers, infrastructure support)
Set-top devices (computerized, interactive controls for television and CD-ROM devices)
Climate and building system controls
Printers, scanners, fax machines
Security systems (alarms, monitors, surveillance systems)
Imaging servers (document management, image retrieval, graphics output)
Factory automation (scanning/tracking systems, assembly lines, robotics, process control)
Edutainment (on-demand video, information, interactive programming)
Next-generation embedded processor hardware (handheld devices, wireless peripherals)
Telephone systems (PBX, POTS, voicemail, digital pagers)
Diagnostic and management systems (wire-level management, software management, pagers)

The list is sure to expand as more developers realize the value that networking can add to intelligent devices. While the possibilities are vast, the level of use and enthusiasm already present in the vendor communities that have signed up with Novell argue for tremendous potential for NEST technologies.

Conclusion

In the past decade, Novell has created a business data network that has become an industry standard for interconnecting systems and services. At the same time, NetWare has also become the world's most popular network operating system, serving over 40 million clients worldwide.

Today, through the NEST program, Novell is leveraging its networking expertise and know-how to extend the power of the network to new intelligent devices and into new business, factory, and home environments. The resulting possibilities are numerous and exciting.

At the office, networking adds considerable value to intelligent devices. It permits organizations to integrate all aspects of their businesses into enterprise networks for easier data flow, simpler management, and more straightforward use.

The potential benefits supplied by networking intelligent devices include:

Lower production costs. By linking embedded systems and product management systems, tighter production controls can be achieved. Likewise, the scope of "just in time" manufacturing can be greatly increased.
More efficient inventory controls. The information path from manufacturing through sales can be fully completed, by including embedded systems for manufacturing, warehousing, shipping, and point of sale. Immediate feedback from product launches, promotions, and competitive introductions can be instantly tracked.
Improved quality. Remote operations or franchisers can be more effectively monitored, and operating conditions better controlled, for more consistent quality and product delivery at all points of customer contact.
Increased productivity. Making embedded systems part of information networks lets documents stay in electronic form, and move fromuser to user, without consuming as much paper or supplies. Inaddition, copiers, printers, and scanners can be monitored and supplied from a central location that constantly tracks status and consumables.

Connecting intelligent devices increases access to information throughout the enterprise. It also lets the information flow to where it is most needed, or can best be used. This strategic use of networking makes critical information available when and where it is needed in an era where effective use of information is emerging as the key competitive advantage.

In the home, intelligent devices are becoming more prevalent as well. The emergence of the information superhighway, and the proliferation of microprocessors in most household appliances, is setting the stage for a new era of networking at home, as well as at work. With increasing needs for interactive use of common appliances -- most notably, the television set for video on demand, home shopping, visual communications, and more -- the possibilities for networking are almost limitless. As a result, the business opportunities are enormous, and most major software, hardware, and communications vendors are scrambling to address this marketplace today.

Novell's delivery of the NEST SDK is a critical step to enabling the further proliferation of networking technology. Ultimately, it is the developers who use this SDK to add networking to their embedded systems who will physically extend the reach and capabilities of networks at work and in the home. To this end, Novell is proud to recognize the over 30 companies -- including industry experts like QMS, Intel, Castelle, Canon, and Lexmark International, but also networking companies like Securicore Telecom, Ltd., with a host of others in operating system, control system, and other system niches -- that have already licensed the NEST SDK. Novell welcomes the introduction of their products to the marketplace.

As more and more developers begin to embrace this technology, we expect that the range of network capabilities and reach will extend far beyond today's boundaries. We would welcome those developers who wish to obtain more information about this exciting technology, and hope that their exposure will generate sufficient interest to get them more actively involved in this trend.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.