Novell Embedded Systems Technology makes NetWare portable and embeddable
Salvatore Salamone
Novell has a vision called pervasive computing. It includes a goal of 1 billion devices connected to NetWare networks by the year 2000. This is an ambitious goal because there are only 40 million NetWare nodes (give or take a few million) currently deployed worldwide. To make it happen, Novell isn't talking about adding just PCs, Macs, and Unix workstations.
Instead, Novell is targeting devices that have not previously been connected to networks. It hopes that half of the billion nodes will come from embedded devices, things such as environmental controls, TV set-top boxes, and even vending machines.
The idea is to make such devices network
-aware. They can then be connected directly to a network and take advantage of such NetWare services as directory and print services. At the same time, these devices would be able to share information with other devices on the network. And, if developers so desire, they may choose to make these devices intelligent enough to be managed through a common control or management system.
The way to make such devices network-aware is to embed NetWare into each device. To do this, Novell has developed NEST (Novell Embedded Systems Technology), which is essentially a portable version of NetWare.
NEST might be deployed, for example, in a building's temperature-control system. NEST-enabled sensors located throughout a building would pass temperature data back to a central location, where the data could be analyzed and actions taken based on the information. Rather than simply cranking up all the air conditioners in an office, a command could be sent only to the NEST-enabled air conditioner nearest a heat so
urce or a device that is the most heat-sensitive (e.g., a minicomputer in an office).
Because many existing control systems use proprietary communications architectures, something as simple as selective cooling of an office is difficult to accomplish. Typically, the temperature sensors and the heating/cooling control system would not have the ability to be synchronized to the extent that a specific air conditioner could be instructed to operate independently from the others on a floor.
The Power of Flexibility
NEST has the potential to change things by offering a common communications architecture (NetWare) and a way to connect devices to that architecture. Novell designed NEST to be a flexible OS because of the large differences in the products on which it will run.
Novell found that between 70 percent and 80 percent of the OEMs interested in NEST use proprietary OSes in their devices. Any embedded NOS (network operating system) would have to be able to work with
all these device OSes. Additionally, a wide variety of processors are used in the devices that are candidates for NEST. And the amount of memory available in many NEST candidates is typically low. Taking these factors into account, Novell developed NEST to be portable, modular, and device OS-independent.
To help deal with the variations in amounts of memory and the different types of functions that might be embedded into a device, NEST uses a modular, layered design (see the figure
"The NEST Design"
). It lets developers select the amount of connectivity and services they want.
The basic functional areas for NEST are the connectivity layer, the NetWare services layer, an application layer, and an OS interface. The connectivity layer provides data transport and low-level services based on Novell's ODI (Open Data-Link Interface). This layer includes several functional areas, including the MLID (Multiple Link Interface Driver), which is the ODI layer that can receive packets
destined for different protocol stacks within the device. The MLID can also let a single protocol stack simultaneously access multiple network topologies, such as Ethernet and FDDI (Fiber Distributed Data Interface).
Right above the MLID is the LSL (Link Support Layer), which handles communications between the MLID and the protocol stacks. IPX and SPX protocol stacks are also within the connectivity layer.
Next comes the NetWare services layer, which gives the device access to the services available from a NetWare server. These include connection, file, print, message, bindery, and authentication services, all of which can be made available to the device. Developers can choose the services they wish to use from client API libraries.
Also included in the NetWare services layer is the NEST requester, which is a module that builds protocol packets and provides send/receive support services. For example, these services might include packet-burst support, to more efficiently transfer bulk dat
a, or auto-reconnect service, to automatically restore a dropped connection. The requester can be used to add packet signatures and RSA (Rivest-Shamir-Adleman) authentication services (if so desired for security).
Riding on top of the NetWare services layer is the application layer, which contains the programs that control the operation of the embedded system. The applications can be provided by an OEM, a third-party developer, and Novell. Two applications are included in the NEST SDK (Software Development Kit) 1.0. The first one is the Embedded PSERVER, a version of NetWare PSERVER NLM (NetWare loadable module), which lets a printer read and transfer files from a NetWare print queue for printing. The second one is the Embedded NPRINTER, a version of the NetWare remote printer program NPRINTER, which lets a printer establish connections to a NetWare server and transfer files from the PSERVER running on that server.
For portability, NEST is written in ANSI C, with OS and CPU dependencies kept to
a minimum (see the table
"OS/CPU Dependencies"
). As a result, NEST supports most common processors, including Intel's x86, AMD's 292xx, and Motorola's 680x0.
The last functional part of NEST is the OS interface, which is called POSE (Portable Operating System Extension). POSE is a Posix-based API that defines all the OS services required by NEST, such as memory management, task switching, synchronization, and timing.
The beauty of this modular approach to NEST is that developers can choose just the functions they need, thus saving system resources such as memory. For example, a device with simple broadcast requirements needs only the MLID and LSL for connectivity and an IPX protocol stack and IPX functions to transmit the information. To provide guaranteed delivery of the information, a developer simply adds the SPX protocol stack. (SPX provides a connection-oriented service between the device and the controller that guarantees packet delivery.)
First Implementat
ions
While NEST must be adopted by equipment manufacturers whose devices have not traditionally been connected to networks, the first practical implementations are coming from a mix of networking hardware vendors and control-system vendors. Among those showing an interest in NEST are CD-ROM jukebox vendor Microtest (Phoenix, AZ) and building-automation product vendor Andover Controls Corp. (Andover, MA).
Several printer vendors have embraced NEST, including QMS (Mobile, AL), Lexmark International (Greenwich, CT), GCC Technologies (Bedford, MA), and Digital Products (Waltham, MA). All four vendors cite a similar reason for using NEST in their products -- tighter integration with NetWare 4.x services (e.g., the directory and authentication services).
The ability of NEST-enabled devices to directly communicate with a central management system (network management or otherwise) has spawned talk of NEST-enabled vending machines. Supplies in the machine can be inventoried remotely. An
y device that contains a consumable, be it toner in a printer or Twix bars in a candy machine, could benefit from NEST.
Besides knowing when to refill a machine, a company could identify buying trends in real time and make adjustments accordingly (i.e., remove a poorer selling product and add extra Twix bars). Or, utility companies could use NEST-enabled meters to read gauges in homes and send a truck to fill up oil tanks when they are getting low.
While there was interest from most of the developers attending the NEST track at Novell's Brainshare conference earlier this year, many said they will proceed cautiously. They've seen similar efforts in the past that have initially shown great promise but have then fizzled out. One example is Microsoft At Work, which offered a simplified way to connect office equipment such as computers, copiers, and printers (see "Whatever Happened to...?," July BYTE, page 30).
NEST may also face a challenge from another industry effort aimed at extending NOS
features to devices that normally do not have them. In February, 15 companies (IBM and 14 Japanese companies, including Ricoh, Matsushita Electric Industrial, and Sharp) announced an initiative to develop a standard for office-equipment communications.
No matter how many vendors eventually support NEST, Novell has a long way to go to reach half a billion NEST nodes from embedded devices by the year 2000. To achieve this lofty goal, NEST devices must be added to networks at a rate of over 250,000 per day -- every day -- until the end of the century.
PRODUCT INFORMATION
NEST SDK 1.0
$50,000 for a five-developer license,
which includes
source code, documentation, support, training, and test tools
Novell, Inc.
Provo, UT
(800) 453-1267
(801) 429-7000
fax: (801) 429-5155
-- CPU
must be 16-, 32
-, or 64-bit
-- OS
must be preemptive multitasking, with thread and semaphore support
-- NEST
reconciles byte order, data type size, and data alignment
illustration_link (8 Kbytes)
The layered NEST architecture ensures processor and OS independence, while letting developers pick and choose the services they need.
Salvatore Salamone is a BYTE news editor based in New York. You can reach him on the Internet or BIX at
ssalamone@bix.com
.
Novell Builds a NEST
