c&g water management system

JENET Training Booklet

An Introduction to Embedded Internet

Technology

of 77

Acknowledgement This document was prepared as part of the EC funded project “Joint European Network on Embedded Internet Technologies” (JENET). JENET is an IST funded project (IST–2000-28422) Disclaimer: The publication of this booklet was first undertaken in 2002. The information contained herein regarding technical implementations, device availability, costs and performance were to the best of the author’s knowledge accurate at that time. However, with the dynamic nature of the semiconductor devices market and the general technology developments in this area it is advised that an independent study should be conducted by individuals or companies considering the adoption of embedded Internet technology in their products. In consequence, no statement in this document is to be regarded as a representation or warranty of achievable results. This information is freely provided but no consequential liability is accepted as a result of its use.

of 77

1. Embedded Internet – The Opportunities Abstract: This chapter identifies the driving forces and market trends that will lead to more appliances and equipment being connected to the world wide web than PCs within a few years. The economic advantages of including embedded Internet technology in products is identified, and prompts provided to identify if such technology could be applied in the reader’s product or service area. 1.1 Introduction For many years the idea that every household appliance could be connected to the Internet has been postulated, with such scenarios as refrigerators that order milk when stocks are low to being able to adjust home thermostats from work offered as examples of the economic exploitation of this technology. Whilst the majority of these such publicised applications are unlikely to make financial sense, a significant increase in embedded networking applications is occurring providing significant economic opportunities for the companies that apply the technology appropriately. To connect a device to the Internet could cost a minimum of an additional 20 to 100 Euro. To justify this cost the embedded Internet connectivity has to add real value and provide guaranteed returns. For most devices, this value will arise from remote management and the delivery of new business services. Remote management of a device can offer several benefits to a company. One application would be the development of an equipment that can activate an alarm by transmitting a message, possibly an email, when the equipment detects that it has approached operational thresholds that indicate imminent failure. The development of this facility will allow a company to schedule its field technicians to make service calls only to those equipment that require maintenance. Alternatively a company could detect when a consumable used in a machine or equipment is about to run out and then deliver to the customer replenishment stock just in time. This facility would allow the company to develop additional sales in the supply of the consumable product and allow the customer to avoid order placement and inventory costs associated with stock level management. Improved technical performance and product simplification can also be delivered. For example, if equipment is developed with an embedded Web server then, once you establish a connection, any browser attached to the Internet can query the device and view its data. This means that the equipment does not require its own display or input interface (such as a keyboard). This could result in lower product costs whilst providing remote monitoring and configuration capabilities. Business innovation is therefore a prelude to the application of embedded networking technology. The identification of an improved method of performing business operations or in providing customer service can successfully lead to the adoption of the embedded Internet technology by the realisation of the added value necessary to offset additional product costs.

of 77

Typical applications for embedded Internet technology in the EC JENET project have included the following:

• Remote vending machine monitoring to ensure stock level management and to detect serious mechanical failure or tampering which would result in the triggering of alarms, for example as applied in money changing machines.

• Devices that can also automatically receive code updates without costly service calls.

• Devices that monitor process values and communicate deviations to management, and provide integrated statistics on use and application of the production equipment on a regular basis, for example as applied in fork lift truck fleet monitoring and management.

• Remote viewing of a controller’s status using embedded Web browsers, for example as applied in farm dairy control systems.

• Sharing of medical information with consultants to allow district nurses to perform initial diagnostic procedures in a home or local clinic.

This list of applications is not exhaustive and significant opportunities for further innovation exists. Figure 1 provides an overview of the potential applications, business models and the venues in which the technology can be applied.

Applications

Business Models

Venues/Devices

– Home• White Goods/Appliances• Game Systems &

Consumer Electronics• Environmental & Security

Systems– Office

• Office Equipment• Environmental Controls• Access controls

– Retail• Scanners & Registers• Lighting & Refrigeration

Systems– Factory

• Automation & Control• Capital Equipment

– Medical• Medical Devices

– Power• Meters• Distributed Generation• Electricity Grid &

Pipelines– Transportation

• Vehicle OEMs• Airplanes• IntermodalTransport• Transportation Services

– Product Suppliers & Innovators– Professional Services

• Consulting• System Integrators

– Info-mediaries• Exchange• Auction• Transaction/Catalogue• Subscription• Advertising

– Solution Providers / Hybrids

–Condition-BasedDevice Monitoring& Repair–Asset Tracking &Management–Building Control–Telemedicine–AutomatedManufacturing–Surveillance &Security–EnergyManagement–Telematics &Fleet Mgmt–Supply ChainLogistics–Personalization

Figure 1: Embedded Internetworking Opportunities

of 77

1.2 Embedded Networking Growth Trends and Factors Several market trends and independent forecasts indicate that embedded Internet technology will become a pervasive technology in the development of the next generation of products. This fact is illustrated by reviewing a few independent projections, as follows:

• 7 million US households in June 2000 owned non-PC digital devices that receive data from the Internet and other digital networks.-International Data Corp.

• By 2004, non-PC information appliances will dominate the market for net-connected devices. -International Data Corp.

• The market for Internet appliances will grow from about $7 billion in 2000 to more than $40 billion in 2005. -International Data Corp.

• By 2005, there will be a market of well over 100 million devices such as Web tablets, Internet gaming consoles, iTV-enabled devices, handheld devices and other emerging technology products. -International Data Corp.

It is also now recognised that Ethernet TCP/IP systems with their high speed (100 Mb/sec) capability provided at low cost provides significant technical advantgaes in the industrial automation sector when compared to the relatively low speed and high cost of proprietary networks and fieldbus networks. All of the fieldbus consortia are racing to redefine their basic protocols so that they work on Ethernet and Internet protocols. For example, Foundation Fielbus HSE, Ethernet/IP, ProfiNet, and IDA,Modbus/TCP are industrial protocols all based on IP over Ethernet. This means that embedded networking is now becoming more widely applied in industrial process applications. Projections indicate that:

• The manufacturing and process control world market will be nearly 100% Ethernet within the next 4 years compared to a level of less than 5% currently.

• Internet-enabled products will grow to 30% penetration of the industrial automation market within 2 years (Automation Research Corp.)

• The manufacturing and process control via Ethernet market will reach around $3.5 billion by 2003.

The growth in embedded Internet devices is projected to grow at a compound growth of 70% over the period to 2005, as the combination of possibilities delivered by the potential cost reduction, value addition and business model diversification facilities provided by its application is more widely appreciated. This is illustrated in Figure 2.

of 77

Figure 2: Embedded Internet Growth Rate

One of the most important factors underlying the growth projections is the pervasiveness of Internet technology, which involves the extension of Internet connectivity to all devices. Emerging application areas for the pervasive, embedded Internet include the markets for:

• Home automation.

• Vehicle telematics.

• Internet-based building

• Industrial controls.

• Smart-energy.

• E-medicine.

Much of this growth is driven by the high value of these markets, and the opportunity for innovative companies to capture new business in these markets. For example, the building control and automation sector in the USA is valued at 30 billion Euro for control systems alone, with another 150 billion Euro market for the provision of services to this market. Embedded networked applications dedicated to delivering imporved performance or to capture part of the services market in building lighting systems, ventilation and air conditioning systems, building security and energy optimisation can therefore provide opportunities for business growth. For example, an optimised deistibuted system for heating control could lead to huge savings for the customer, a 10C saving is equivalent to a saving of over 1 million USD for an American chain operator with 800 locations. Some of the wide range of opportunities in these sectors is provided by the application of embedded internet technology is indicated in Figure 3.

of 77

Figure 3: A Sample of the Embedded Internet Opportunities

The driver factors in the process of embedded Internet adoption are illustrated below.

RevenueOpptys

forProductOEM

Total ProductsWorldwide

Total Products Available ForInternet-Enablement

Total Internet-Enabled ProductsDeployed By 2005

CustomerSatisfactionImprove-

ments

CostAbatementfor Product

OEM

I-E ProductSet-up &

Automation

Network/LAN

Installation

Internet-EnablementComponents

Technology Costs Solution Benefits

Several Billion

A Billion

Millions

•MPUs/MCUs

•Ntwkg S/W•Comms.Port

•LANwirings

•Gateways•WAN/ISPconnection

•SystemConfig

•Rules &Security

•Main-tenance

•Labor &RepairPersonnel

•AssetOptimizing

•Personal-ization

•Preventa-tive Repair

•Energy &Mgmt

•Cross-selling

•ServiceContracts

•ProductDesign

Profit

Figure 4. Embedded internet Technology Drivers

of 77

1.3 Towards New Opportunities The identification of new business opportunities suitable for the application of embedded Internet technologies requires a shift in the perspective of management in relation to where their businesses can earn profits in the future. Pressure for cost reduction as products mature can result when the product delivered satisifies all customer needs, possibly after several design upgrades over the product life. As indicated in Figure 4, at this transition time the opportunity may exist for the development of associated services or the supply of conssumables to the customer to capitalise upon the existing business relationships and maintain or grow profit levels.

Level ofPerformanceof DeviceRequired ByUsers

Time

NetworkedMarketplace

Non-Networkedmarketplace

Transition point

Unfilled needs

The device becomes secondary tothe value it brings to thecustomer. Services become themeans to cultivate an ongoingcustomer relationship.

Networked Product is “goodenough” and therefore irrelevant/ invisible. Now, it shouldsupport the customer experience.

Non-networked Products• High profit margins• Med-high growth• High volumes

Networked Products• Low product profit margins• Average growth• Mixed volume segments

Profits come from theproduct/device

Profits come from consumables,services, and content

Figure 4. The Transition from Stand Alone to Networked Products

To consider whether a company can deliver a commercial success through the implementation of embedded Internet technology the following factors should be considered by the company’s management team :

i. Can the product be improved by the adoption of embedded Internet technology. For example, can any of the following improvements be delivered:

• Reduce product cost by the removal of unnecessay local features as remote access is provided.

• Improve technical performance through the sharing of data between networked units.

• Improved process control through the application of distributed networked control systems.

ii. Can the use of Internet communications deliver improved customer satisfaction by, for example, the delivery of:

of 77

• Diagnose preventative maintenace requirements to reduce downtime.

• The delivery of product upgrades without product return or recall.

• The provision of remote diagnostic services to minimise response time to requests for assistance.

iii. Can the embedded Internet capable product allow the company to become more effective in its operations by, for example:

• More effectively managing its field maintenacnce and service engineers by the application of the more accurate status information.

• Expanding its sales area, whilst using the improved communications facilities to allow the exisiting field maintenacnce and service engineers to manage this expansion.

• Manage its inventory better, through the use of improved information supplied via remote diagnostics.

• Utilise aggregated information from the distributed systems to determine trends or opportunities which can be exploited.

iv. Can the company identify service opportunities which embedded Internet technology would enable, and is there a commercial demand for these services: For example:

• Does the company supply consumable products, which advance ordering information provided by the Internet conneted equipment would allow the company to supply in a more timely or cost effective manner?

• Does the existing product enable support services to be delivered to the customer, whch can now be more effectively delivered by the company.

• Can new products, for example fleet or asset management software utilities, be delivered to the client based on the improvements in information availability.

These, and similar, opportunity identification processes can lead the company towards new business opportunities and improved growth prospects.

Acknowledgement: This document utilises source data provided by the Harbor research white paper, June 2001, ‘Internet–enabled products are driving value creation for business’

of 77

1.4 Issues in getting Started in Embedded Internet Technology Once convinced of the benefits that embedded Internet connectivity can supply a company with, where does one start? The details of TCP/IP and server systems throws up a host of new system level challenges to a company looking at this technology for the first time. Fundamentally, the major issue to address is one of connectivity. Consider such issues as : • What data do we need? • What is the value of this information? • Is the access to the data in a time critical? If yes, relying on embedded Internet

solutions may not be the best approach. • If I have this information provided, does it impact on connections to other systems

or on the security of the system? • Who should access this information and why? The flow and the value of information in embedded Internet systems must therefore be a major design consideration. Given the value of the information the commercial decision is what level of additional cost is justified by increases in purchase price, growth in sales in other areas (e.g. consumables) or savings in other areas (for example, servicing costs). This will determine your target cost criteria. Given a satisfactory outcome to the above the main technical issues will be: • Which technical solution should I adopt? • Do I have the appropriate design skills to deploy? • What development costs and budgets should I allocate? • What are the technical risks? • Do I really need to know TCP/IP protocols in detail? What is the essential level of

knowledge required on TCP/IP? The answer to these and other questions are provided below and in the practical case studies provided on the JENET web site, www.eurojenet.com.

of 77

2. Internet Protocols Required For Embedded Systems

Abstract: This chapter discusses the OSI model for the TCP/IP (Transmission Control Protocol / Internet Protocol) that underpins embedded Internet communication systems. The utilisation of the various lower level protocols in establishing the Internet communication links is explained, and implementation options including the use of sockets is explained. This section provides an introduction to the topic for readers with no or little previous TCP/IP knowledge.

2.1 Introduction The standard model for networking protocols is the International Standard Organization's Open System Interconnect (ISO/OSI) model. The OSI Model separates the methods and protocols needed for a network connection into seven different layers (see Figure 1). Each higher layer relies on services provided by a lower-level layer. Two programs on different computers communicate. The seven layers are,

• Physical layer: The lowest layer of the model, it provides the transmission of data. This layer defines electrical and mechanical properties, such as cable and connector type, voltage levels and timing.

• Data-link layer: This layer controls the transmission of blocks of data between network peers over a physical link. It monitors and resolves errors that may occur on the physical layer. The data-link layer is usually subdivided into two sublayers, called the Logical Link Control (LLC) and Medium Access Control (MAC) sublayers.

• Network layer: The network layer defines how data packets get from one point to another on a network and what goes into each packet. It defines different packet protocols, such as IP (Internet Protocol) and IPX (Internet Protocol Exchange). These packet protocols include source and destination routing information. The routing information in each packet tells the network where to send the packet to reach its destination and tells the receiving computer from where the packet originated.

• Transport layer: This layer manages the flow of information from one network node to another. It ensures the packets are decoded in the proper sequence and all packets were received. It also identifies each computer or node on a network uniquely. The transport layer is the first layer that becomes differently implemented on different networking systems.

• Session layer: The layer provides the capability for cooperating applications to synchronize and manage their dialog and data exchange.

• Presentation layer: This provides services that interpret the meaning of the information exchanged.

• Application layer: This layer directly serves the end user. It supports end applications such as file transfer and database access. It controls how the operating system, and its applications, interacts with the network.

of 77

Application

Presentation

Session

Transport

Network

Data Link

Physical

7

6

5

4

3

2

1

Layer ExchangeUnit

Application

Presentation

Session

Transport

Network

Data Link

Physical

Network

Data Link

Physical

Network

Data Link

Physical

APDU

PPDU

SPDU

TPDU

Packet

Frame

Bit

Application Protocol (FTP, TelNet, SMTP, NNTP, ...)

Presentation Protocol

Session Protocol

Transport Protocol (TCP, UDP)

Communication Subnet Boundry

IP, ARP, RARP, BOOTP, DHCP

Figure 1: The ISO/OSI Network Model The development of the OSI model was driven by the goal to create an international standard for a layered protocol stack for communications. However, a different protocol stack was developed earlier to connect different networks together. This protocol stack, the TCP/IP protocol, was never intended to be an international standard, but is nowadays the standard protocol stack for computer networks. Although the OSI and the TCP/IP protocols have a different number of layers, it is possible to compare some of the layers. Figure 2 shows the OSI and the TCP/IP protocol stack side by side. Similar functions are perfomed by adjacent layers.

of 77

OSI model TCP/IP model

Application Layer

Presentation Layer

Session Layer

Application Layer

Transport Layer Transport Layer

Network Layer Internet Layer

Data link Layer

Physical Layer

Host-to-Network Layer

Figure 2: TCP/IP protocol stack The higher layers of the protocols stacks are usually technology independent. Only the lower layers in the OSI model and TCP/IP model are technology related. The most commonly used technology for LAN is the Ethernet. The Ethernet is an implementation of the IEEE standard IEEE802.3.

2.2 The Layers The layers of the OSI and TCP/IP models have different functions. Each layer provides services to the layer above and expects services from the layer below. This allows the exchange of one layer implementation with another implementation.

2.2.1 The Host-to-Network Layer (Ethernet Technology)

The data-link layer in the protocol stack is divided into two parts, the Logical Link Control Sublayer (LLC) and Medium Access Control Sublayer (MAC). While the LLC implements functions like flow control, the MAC sublayer implements the technology used. The implementation of the Ethernet sits therefore in the MAC sublayer.

The properties, procedures and definitions associated with the Ethernet are contained in the IEE Standard 802.3. A number different implementations of the Ethernet technology exists (Figure 3). The term ‘base’ in the table refers to a communication system that does not modulate a carrier with the information.

IEEE Standard Technology Cable type Max. length 802.3 10Base5 Thick Coax (RG-8) 500 m 802.3a 10base2 Thin Coax (RG-58) 185 m 802.3l 10BaseT Cat 3, 4, or 5 UTP 100 m 802.3j 10BaseFL Fiber 2000 m 802.3u 100BaseT Cat 3, 4, or 5 UTP 100 m

Figure 3: IEEE standards for different Ethernet technologies. The communication in the Ethernet layer is an exchange of Ethernet frames, which cannot contain less than 46 and more than 1500 bytes of data (payload). Every

of 77

Ethernet frame consists of a header, data and trailer. Figure 4 shows the structure and contents of a Ethernet frame (802.3). The preamble (7 bytes) and start frame delimiter (1 byte) provide the syncronisation and the start of the actual frame for the listening station. Source and destination address (each 6 bytes) hold the MAC sublayer address, which is a fixed hardware address for the network adapter. The length of the data, which can vary between 46 and 1500 bytes is stored in the data length field (2 bytes). At the end of the Ethernet frame is a trailer, which contains a pad field and the CRC checksum. The purpose of the pad field is to pad the frame to its minimum size should the payload be less than 46 bytes. The CRC checksum verifies the integrety of the frame. The actual payload follows in the data field. The payload itself will have its own header and payload part, which are dealt with by the next layer in the chain. This is the concept of protocol layers. Ethernet frames are completely independent of each other. The Ethernet protocol does not care about, whether the packet is received by the destination machine or not. This is the role of the upper layers. The Ethernet layer participates in the correction by dropping the packets that have a wrong CRC.

Preamble(7 bytes)

Destination(6 bytes)

Source(6 bytes)

Data(46 - 1500 bytes)

CRC(4 bytes)

S L P

Start Frame Delimiter(1 byte)

Pad(n bytes)

Preamble8 bytes

Header14 bytes

Data46 - 1500 bytes

Trailer4 bytes

Frame size64 - 1518 bytes

Length Count(2 byte)

Figure 4: Structure and contents of an 802.3 frame. The MAC address in the Ethernet is uniquely associated with each Ethernet card and usually assigned at manufacture. In practice the address is stored in a separate serial EEPROM memory chip on the interface card. Blocks of addresses are assigned by the IEEE to each manufacturer. Every Ethernet card has its own unique number stored in it. It is possible to change this number, and apart from some simple restrictions (the first byte in the sequence must have a 1 and a 0 as its lower significant bits), any number can be used as long as there are no clashes with other cards in the network. There are new embedded Ethernet products providing a single chip combination of the Ethernet interface and its complementing hardware. That means that the MAC numbers are stored into the interface chip itself. MAC address should not be mistaken with the IP address, are 4-byte address assigned by the network administrator.

2.2.2 The Network Layer

The network layer is the lowest layer involved in the end-to-end transmission and shields the higher layers from the type and topology of the underlying network. The network layer provides three main functions: addressing, packaging and routing. The mapping of the IP address to the physical MAC address is performed in this layer. The IP protocol is located in this layer and provides a connection-less, non-guaranteed delivery of information. This means that each packet is routed independently and no checks are performed whether the packet has arrived correctly or not. The

of 77

functionality of the IP protocol within the TCP/IP protocol stack is explained in more detail in the IP protocol section.

2.2.3 Transport Layer

The transport layer provides an end-to-end communication between computers using ports. The two protocols defining the behaviour in the transport layer are the Transmission Control Protocol (TCP) and the Universal datagram Protocol (UDP). Both are described in a later section.

2.2.4 The Application Layer

The application layer is used by network-based applications, such as telnet, FTP, DNS, NFS and HTTP. Data originates at this layer.

2.3 The Layer Protocols A number of protocols are used to make the communication on computer networks possible. These protocols are located within the different layers of the protocol stack depending on their function. Figure 5 shows a summary of these protocols.

Application

Ali AliInternetWWW, E-Mail,XML, EDI, etc.

FTPTelNet SMTP TFTPNFS/(RPC)

BOOTP/DHCP DNS

Socket-Interface Socket-Interface

TCP UDP

IP

Ethernet

ARP RARP

Figure 5: TCP/IP protocols and Services

of 77

2.3.1 ARP

ARP stands for Address Resolution Protocol. ARP is a simple query-response packet protocol used to match workstations hardware addresses and IP addresses. In order to establish communication, the ARP protocol sends out the IP address of the target computer, requesting the target MAC address. A special MAC broadcast destination address (0xFFFFFF) is used to address all Ethernet stations on the network. The broadcast message basically asks who has the wanted IP adress. The station with the target IP address allocated will then reply with a packet stating its hardware MAC address. In high-level operationg systems (Unix, Windows...) each computer builds up and maintains a local table of IP vs MAC address pairs. An ARP query message is only sent out to another station, when no entry of the IP is found in the table. The table is dynamically maintained, and updated every few minutes.

An embedded Ethernet device must include some form of ARP reply mechanism in order to respond to ARP requests made by other stations on the network. The embedded Ethernet device also needs to include the mechanism to send out ARP requests to other machines. This is one of the necessary overheads that increase the amount of code required in the embedded Ethernet device.

2.3.2 RARP

RARP is a protocol used by Sun and other vendors that allows a computer to find out its own IP number. It is a simple protocol, which can easily be implemented on a microcontroller.

2.3.3 IP

IP stands for Internet Protocol, and is the fundament of TCP and UDP communication. IP divides each message from the upper layer (Transport Layer) into packets. Each IP packet has itself a header and a payload. The basic document for IP is RFC 791. The most important information contained in the IP header are the source and destination IP addresses. Other fields include a checksum, a fragmentation pointer, a protocol code for the payload, and the payload itself (see Figure 6).

32 Bit

Byte 0Byte 4Byte 8Byte 12Byte 16Byte 20

Version Length Service Type/DS Length (total)Identification Flags Fragment Offset

Time to life Protocol Header-ChecksumInternet Source Address

Internet Destination Address

[Options] [Padding]

DATA

Figure 6: IP Packet IP datagrams are independent of each other and no built-in error protection or recovery is provided. The role of IP is the abstraction above all hardware dependent transport mechanisms (fibre, radio, phone, Ethernet).

of 77

IP is responsible of getting the data block to its destination. Its main contributions are addressing, routing and fragmentation. The method employed for fragmentation is relevant for embedded systems. Fragmented packets include a pointer indexing the position of the first byte of their data payload in an imaginary 64kb data buffer. Therefore, each IP packet contains exact information about the position and size of their payload within this imaginary buffer. This allows for fragmented packets to be received out of sequence. A receiver accumulates packets until they all neatly fit into a contiguous block. It follows that fragmented IP packets are not completely independent of each other. This will introduce a time element in any system. A receiver for example, has to consider when to give up waiting for missing out of order packets, and dump any previously stored.

Fragmented packets can cause problems with small embedded systems. Theoretically, a 64kb buffer needs to be allocated for every first out of sequence packet received, i.e. one buffer for every different open socket. This would be impractical for embedded system with a small and limited RAM. A way out of this is to disallow or ignore fragmented IP packets. However, this may cause problems in systems dealing with long, block-encoded data streams such as voice or video. This is less of a problem when using TCP (see later on), as TCP can use small segments to start with.

In a typical situation, an embedded system may receive data streams from many sources or originators, possibly at the same time. The microcontroller will need to keep track of all data streams to ensure the correct operation. High-level systems can support threads which are able to manage multiple connections easily. Small microcontroller systems, on the other hand, need to be programmed efficiently to handle this type of traffic.

2.3.4 ICMP

The Internet Control Message Protocol (ICMP) is not a message transfer protocol. It rather provides an internal maintenance messaging service. One of the most common uses for ICMP is PING. PING is a method where a machine can query another machine by transmitting a short ping message, and wait for an echo response. It is useful to provide the PING service in an embedded system as a low-level functionality test. Also, ICMP replies are commonly used as response to failed UDP datagrams. An embedded system should incorporate simple facilities for responding with ICMP to unsuccessful UDP transmissions. Documentation about ICMP is provided in RFC 792, 950, 1812, 1122, 1191 and 1256.

2.3.5 UDP

The User Datagram Protocol (UDP) is a simple Transport Layer Protocol. It provides a connectionless, unreliable transport service with no error or flow control mechanisms. UDP datagram is nothing more than an IP packet with an extra addressing field called the port number (see Figure 7). The port number in a UDP packet determines which serving application has to answer to the query. There are well-known service ports, which are coordinated by the IANA (Internet Assigned Numbers Authority).

A machine sends a UDP-packet without further events, i.e. the sending machine does not know if it arrives. In reliable networks, such as LANs, UDP can be a good mode of transporting data. It would be used normally for simple file transfers, remote booting of machines or anywhere where a failure to receive is not a disastrous issue. Because of this simplicity, UDP is a simple protocol to implement in an embedded

of 77

system. Error recovery can be implemented at higher protocol level (user level), and can take the form of mindless repetition to a simple acknowledgement-based datagram response.

Byte 0Byte 4Byte 8

Source Port-NumberLength

DATAChecksum

16 Bit

Destination Port-Number

16 Bit

Figure 7: UDP Packet

2.3.6 TCP

The Transmission Control Protocol (TCP) is different to UDP and to any of the protocols described previously. TCP provides a connection (point-to-point) oriented, reliable, byte stream service. Error protection and flow control mechanisms are also implemented in the Transmission Control Protocol. The main document for TCP is RFC 793. With additional information in RFC 896, 1122, 1323 and 2018.

TCP requires the two stations to establish a connection first, before any data exchange can be performed. Once the connection is established, data can be exchanged between the two stations. The data exchange is terminated by closing the connection. TCP divides the messages from the higher layer into segments. Specially flagged segments are used to synchronize counters and timers at either end when establishing a connection. Figure 8 shows the fields in a TCP packet.

Byte 0 Source Port Destination Port

32 Bit

Byte 4Byte 8Byte 12Byte 16Byte 20

Sequence NumberAcknowledgment Number

Offset Flags WindowChecksum Urgent Pointer

[Options] [Padding]

DATA

Figure 8: TCP Packet All data send via TCP are acknowledged. Rather than acknowledging each segment individually, TCP uses a pointer where the receiver acknowledges the position of the index or pointer of the last reliable block of data received (see Figure 9). Each segment thus carries a block of data plus an index pointer into an imaginary array of bytes.

of 77

TCP-Segment 1

ACK 1

Sender Receiver Sender Receiver

TCP-Segment 2

ACK 2

TCP-Segment 3

ACK 3

TCP-Segment 1TCP-Segment 2TCP-Segment 3

ACK 1-3

Transmission Tim

e for 3 TCP

-Segm

ents

Transmission Tim

efor 3 TC

P-S

egments

Figure 9: TCP Packet Acknowledge

With this scheme there is no need to acknowledge every segment, a single acknowledgement can be sent for more than one transmission segment received. A form of data flow control is provided in the transmitter and receiver. Both operate a data window scheme,telling a transmitter how many more bytes the receiver is able or willing to accept.

TCP can be tuned to provide an efficient flow mechanism for a particular channel's characteristics by constant adjustment of the windows and delays. In such a channel, the transmission line is nearly constantly active all the time, with very few acknowledgements sent back.

2.3.7 DNS

DNS stands for Domain Name Service. The cause of using DNS is that it is simpler to handle with human-understood names than with the IP addresses. This service maps these machine names to the respective IP addresses. Generally, there is a single DNS-server on a local network. It has a list of the machine names on the whole network and their associations to the IP addresses. The clients know the IP address of the nameserver and send him a request whenever an IP address of another host is required. The request includes the name of the machine and the server replies with the asked address. Most of the operating systems keep a local list of the communication partners and their addresses up-to-date. DNS is described in RFC 1033, 1034 and 1035.

2.3.8 Telnet/Secure Shell

Telnet is a terminal emulation program based on TCP communication. It allows the user to connect to another machine as remote user. The user can enter commands through Telnet, which will be executed as if they were entered directly on the server console. Telnet requires user name and password to start a session. A session consists of commands understood by the server. Telnet is described in RFC 1123.

Telnet has the disadvantage that it can be listened to by everyone in the network. A hacker would have the possibility to log in the embedded host and cause damage. The

of 77

solution for this problem is a protocol called secure shell. The secure shell provides an encrypted communication that can not be listened to.

2.3.9 FTP

The File Transfer Protocol (FTP) allows computers connected to the network to exchange files, regardless of the computer platform. The rules and commands of FTP are described in RFC 412. Using FTP requires a user-level application on the client machine and a daemon on the host machine. The main possibilities supported by FTP are:

• Send, receive, delete and rename files

• Create and delete directories

• Change the current directory

• File tranfer in binary or ASCII mode

The protocol uses two ports: port 21 is responsible for the commands and port 20 for the data transfer (see Figure 10).

Most embedded solution need only the client part. It is used merely for retreiving program parts or calibration informations. FTP is the fastest way to transport large amounts of data due to the missing overhead. Nevertheless it is not suitable for dynamic communication, because of its session oriented fuctionality. A secure substitute for FTP, called SFTP, is provided by secure shell.

Data-Process

Rudder-Process

FTP Server

Por

t 20

Command Channel

Data-Process

Rudder-Process

FTP Client

Port 21

Data Channel

Por

t 21

Port 20

Figure 10: FTP Connection

2.3.10 HTTP

This is the well-known internet protocol for browsing on the Internet. It stands for Hypertext Transfer Protocol. HTTP is a very useful application layer communication protocol for embedded systems. After all, almost all of the workstations connected to the internet have a browser, and almost everyone who has got such a machine knows how to use it. HTTP was developped to transfer Hypertext documents between two computers. These documents are written in HTML (Hypertext Markup Language). The basic idea of this language is to seperate the fields of the document with the same layout. They get a different format assigned limited by tags. The aims of the HTTP developpers were:

• Simple ASCII-based Request/Response-protocol (see Table 1)

of 77

• Minimal load of the sever by opening a new TCP connection for every request. The server does not have to save its status.

• High speed (no status)

Method DescriptionGET Request for reading a web pageHEAD Request for reading the header of a web pagePUT Request for writing a web pagePOST Attach a resourceDELETE Delete a web pageLINK Link two resources

Table 1: HTTP Commands The HTTP-transaction for the transfer of a document from the server to the client is as follows:

1. The connection: The client makes a connection to the server over the HTTP port 80. The port number can also be determined by the web address itself.

2. The client sends a document request to the server (e.g. GET-command)

3. The server answers by sending the requested document. If an error occures, the server creates a file describing the art of the error and sends it to the client.

4. The server closes the connection.

Assuming that the informations on the host are static, the microcontroller does not have to respond to all the queries because these informations will be cached. That means a lower load for your host. On the other hand, an embedded processor that has to send different (updated) information each time must be more powerful. It has to invoke an executable that generates the packets to be sent for every query. The data flow direction by HTTP is mostly from the target (host) to the workstation (client). The target sends the information in form of HTML documents, which the client will process. When the reverse direction is needed, special forms must be use.

2.3.11 Mail Protocols

It is usually expected from an embedded system to report every or some changes in its state. A vending machine for example must be able to say to an operator that the soda supply is empty. In this case the embedded controller must send an Email to the operator. Although there are three kinds of mail protocols in the internet, the sender's viewpoint is almost the same for all of them.

• SMTP: stands for Simple Mail Transfer Protocol, documented in RFC821. It is the most primitive mail protocol. The sending machine queues the mails that could not be sent. SMTP uses the TCP port 25.

• POP: Version 3 of the Post Office Protocol (POP-3), documented in RFC 1725, is designed for user-to-mailbox access. This means that the mails are latched into a mail server and the user can fetch them at the appropriate time. The embedded sender is freed and does not have to send the mail once again. POP uses the TCP port 110.

of 77

• IMAP: stands for Internet Message Access Protocol (IMAP) version 4 revison 1 and is documented in RFC 2060. It represents an improvement over POP by allowing the use of many folders in a mailbox. IMAP uses the TCP port 143.

Most embedded target need only the sending part of the mail protocol. The simplest way to realize this is to use the SMTP alternative and a mail server. The received message must be always acknowleged by the server. Every SMTP packet begins with a method identification according to Table 2.

Method DescriptionHELO IntroductionMAIL Specification of the senderRCPT Specification of the receiverDATA Sending the messageQUIT EndVRFY Verify the usernameEXPN Specification of the folderlists

Table 2: SMTP Methods

2.3.12 BOOTP

Short for Bootstrap Protocol; this protocol enables a machine to discover its own IP address, the IP address of a BOOTP server on the network, and a file to be loaded into memory to boot the machine. Using BOOTP, a machine can boot without requiring a hard or floppy disk drive. For an embedded system, this equates to a ROM-less implementation, with the operation code downloaded at boot time. The protocol is defined by RFC 951.

There are many projects including the BOOTROM-Codes supporting BOOTP. These are destinated to work with standard PC Ethernet interfaces having the corresponding socket (mostly 25xxx EPROMS). The embedded variation of this code is similar to this model, with the difference of the bus architecture.

2.3.13 DHCP

DHCP is Dynamic Host Configuration Protocol, which is an enhancement of BOOTP (backward compatible) and described in RFC 2131. DHCP allows for dynamic allocation of network addresses and configurations to newly attached hosts. A a leasing mechanism is used by DHCP to allow recovery and reallocation of network addresses. DHCP is recommended for big networks. Both DHCP and BOOTP can be routed, while RARP is limited on the local network.

2.3.14 TFTP

TFTP (Trivial Transfer Protocol) is a simpler version of FTP. It uses the UDP protocol and provides no security features in terms of a login. The client tells the server the path of the demanded file and receives it from the server. A TFTP packet begins always with a 2-bytes Opcode, which is followed by a block number, a error code or the data itself (depending on the Opcode). The default size of a TFTP data packet is 512 bytes.

of 77

2.4 Client/Server Communication The World of TCP/IP communication is based on a simple scheme called Client/Server. These are two communication partners (machines/programms) connected to another. The client requests a resource or a service from the server using a communication protocol (see Figure 11). The client does not have to worry about how the connection to the server is made. As far as the server and the client are connected, they are talking directly to another. The communication is made in our case with the mentioned TCP/IP Protocols.

Server

Client

Request

Answer

Figure 11: Client/Server Communication

2.5 Booting over LAN Some embedded applications need more storage than a small ROM can provide. Others need to use a bigger filesystem than a Ramdisk (e.g. to save measurements) and cannot contain a hard disk because of the environmental conditions. There may be some requirements, that would imply changing the software every time the system boots. Booting over the network is a way to solve such problems. Because the embedded system has already an Ethernet interface, it would be able to boot through it. The embedded system would only need a bootrom containing the driver for the Ethernet controller and an implementation of a LAN-Booting protocol. The controller gets first its own IP adress from the server by sending its own hardware adress (MAC). This the job of the RARP/BOOTP/DHCP protocols. The server determines then which file the embedded system needs for booting. The controller requests the file by making a TFTP request and receives it from the hard disk of the server. The kernel has got the possibility to mount a filesystem on the file server using NFS (see Figure 12). Netbooting is used mostly on UNIX-based platforms (Linux, BSD...).

of 77

MC Server

My IP?

Your IP

Code?

mount request

Kernel

Root Directory

RARP/BOOTP/DHCP

TFTP

NFS

MAC-Address

IP-AddressBOOTRom-

Loader

Booting

INIT

StartingApplication

Figure 12: Netbooting Sequence

2.6 Implementing TCP/IP on your Microcontroller There are two basic approaches for the software on an embedded microcontroller. The first is to use ready-made implementations of embedded operating systems (e.g. embedded Linux, Windows CE, QNX...). This requires large memories (RAM and ROM) and fast controllers. Most of these operating systems are commercial, resulting in additional cost for this alternative, but a fast result. The second approach is to program a purpose-made operating system. This would involve the programming of low-level language (Assembler) or C routines. The second approach can have the advantage of lowering the demand on the harware and therefore, lowering cost and increasing speed.

2.7 Using High-Level Operating Systems The use of available operating systems decreases the developing time. There are many systems available that include the complete TCP/IP stacks. The developer can use the operating system routines and has only to program the application. It can be also written in abstract high-level languages (C++, Java, pearl, python, PHP...) using ready-made libraries. This means also that there is a reduced learning time for the functionalities of the hardware, because it is the operating systems shields the programmer from it. This solution is also the efficient way to implement netbooting applications. All of the required protocols (BOOTP/DHCP/NFS) are available and their configuration is relative simple:

• One simple operating systems is MS-DOS from Microsoft. Although the code is size is quite small and the system can be loaded from a small ROM, the implementation of the TCP/IP services must be implemented on top of it. This system is only available for the Intel x86 core and there are a number of projects using this technology.

• µC-Linux is one of the renowned embedded operating systems. It is designed for targets that do not have MMU (Memory Management Unit). These processors are not able to manage virtual memory (holding a table matching virtual addresses to physical adresses - RAM/mass storage). They are, in

of 77

comparison to the MMU processors, much cheaper. µC-Linux works on the most of the Motorola 68K derivatives, Motorola Coldfire, QUICC, ARM7, ETRAX, Intel i960... .

• Windows CE is also a new standard for embedded targets. It has the advantage to be a well known commercial embedded operating system that is also used in some PDAs and mobile phones. The required TCP/IP protocols are available under Windows CE. There is also support for booting over the net, but it is mostly for Graphical User Interface (GUI) diskless workstations. Windows CE works only on processors supporting MMU and provides a soft real-time platform. Windows CE and µC-Linux are sometimes favoured because of their compatibility with the standard operating systems for desktop workstations.

• RTLinux is the hard real-time flavour of Linux. It is based on a real time micro-kernel, which runs the Linux-kernel is an application with low priority. This means it has pre-emtive features and benefits of all the tools and API of a normal Linux. RTLinux runs on almost every x86, PowerPC and Alpha. RTLinux/Pro also supports MIPS. There is a tiny implementation of RTLinux which fits on a 1.44MB floppy and runs on i486 machines. It can be used for embedded applications and is booted over the net. The system requires admittedly 4MB RAM.

• VxWorks is based on the WindRiver real-time microkernel. It provides advanced networking support, powerful file system and I/O management, C++ and other standard runtime-support. It supports all of the mentioned TCP/IP protocols and is available on most of the popular CPU platforms.

• QNX is a UNIX compatible hard real-time operating system running on MIPS, PowerPC, SH4, StrongARM and x86-based processors. It provides a nice development platform and plenty of modules designed for embedded systems.

• Microwave's Real-Time Operating System OS 9 is a modern process-based system. This feature makes it a better choice than common threaded kernels for complex applications dealing with protocols and networks. OS 9 is available for all the mentioned 16-bit (or larger) processors.

2.8 Programming the Services yourself The TCP/IP stack is a complicated implementation and most of the embedded applications do not need its complete stack of services. The mentioned vending machine suffices a SMTP implementation to send its status. A review of the required services is usually performed before beginning the programming task. In the case of a self-made software, the algorithm is mainly restricted to the support of ICMP and UDP. This means a relative small amount of code is needed to have the possibility of a network communication. Implementing the full TCP/IP stack in an embedded system is not trivial. Including all combinations of events, states and actions will inflate the required program and data memory space, which is already limited in a microcontroller. In addition, threads are not easily implemented in smaller devices. Fortunately, some simplifications can be made by taking a number of assumptions, for example, long-term connection coherence and resilience to repeat missing data. Depending on its use, it is possible to implement a workable light version of TCP in an embedded processor.

of 77

2.9 Using Sockets Sockets are the file descriptors allowing the communication over TCP/IP. It was initially implemented for the UNIX-World. There are TCP- and UDP-based sockets (see Figure 13). A TCP communication requires a server program and a client program, which are described in the following sections.

Practise

TCP

IP

UDP

Practise

TCP

IP

UDP

Practise

TCP

IP

UDP

Computer A Computer B Computer C

Socket-Connection Socket-Connection

Figure 13: Socket Connections

of 77

3. Alternative Design Approaches

Abstract: There are a number of alternative solutions available to embedded system designers to make their products Internet capable. This section provides a generalised overview of these alternatives and provides information as to the practical implications in terms of cost, memory requirements and / or processing speed of these solutions. The selection of design tools to support embedded Internet design solutions is also covered.

Internet appliances use technologies that include TCP/IP (Transmission Control Protocol/ Internet Protocol) network protocol, embedded web clients and servers. To avoid creating a proprietary network, it is essential to use web technology for Internet support. TCP/IP is the favoured standard network operating system or protocol. It is the most widely used protocol, and should be used unless the appliance has to support an existing proprietary network. TCP/IP allows the design engineer to connect and control devices, and communicate with software on almost every operating system over most transport media. TCP/IP software stacks are commercially available and some are optimised for embedded and real-time operation.

3.1 Overview of Alternative Implementation Approaches Internet products use component, module or software technologies that include TCP/IP (Transmission Control Protocol/ Internet Protocol) network protocols to be implemented. The range of design approaches that can be used to implement the TCP/IP stack will vary depending on product volume, cost and specification. However, the solution category will fall into one of the following:

3.1.1 Hardware TCP/IP Peripheral Devices:

Hardware peripheral devices offer potentially a fast and cost effective approach to implementing internet connectivity in a wide range of products, especially for companies which do not want to change to a new embedded processor technology. These devices offer most of the functions of the TCP/IP stack, interfacing with a master processor and external modem / Ethernet device using serial interfaces. Several vendors provide internet connectivity ICs including those from Connect One and Seiko Instruments. These devices offer the potential of not needing to redesign the basic product with a more powerful processor to run the Internet protocols, nor to add extra memory to store the protocols, nor to change the operating system. The devices offer the potential for 8 bit processors to connect to the Internet, although available temporary memory storage requirements need careful consideration.

The advantages of this approach are evident. For a first user of the technology, buying a device that offer all the functionality of the TCP/IP stack plus additional interfacing functions and a variety of useful applications, must a very big bonus. It saves the company the time, cost and risk associated with a major software development project, if the company is to choose the software route.

Most Internet connectivity chips have standard interfacing options with the master processor of the system or product. This enables the design engineer to fully control the chip as a slave device, and instruct it to perform various Internet connectivity and specific application tasks from a processor that is well known to the designer. This has very powerful implications. First, it means that the design engineer in a company

of 77

does not have to change the processor that already exist in the product or the processor family that the company uses as standard, just to implement internet connectivity. Sticking with the processor family that you are used to work with and most probably have invested in its development tools is significant benefit in cost and time to market. Secondly, this opens the way for making a wide variety of products that are based on low cost and general-purpose microcontrollers to become web enabled. This means that even 8 bit, and possibly 4 bit, processors with their limited capabilities to implement the most basic functions of internet communications can potentially be used to develop internet-ready designs with the help standard internet connectivity chips.

The following issues are also relevant in considering this technology solution: • In comparing hardware solutions against software options to consider what

features are implemented in the IC that you want to buy. Although the devices in the market today have implemented most of the important stack functions and additional options, some vendors may produce cut down versions that may not include all the functions required for a specific applications. In fact, this issue should also be considered when evaluating software implementations of TCP/IP.

• The attraction of most commercial TCP/IP chips is that they represent a single chip solution to implement complex functions. However, the design engineer should consider if this is the case for all devices in the market. It is possible that certain chips may require additional support chips, such as memory or interfacing chips for external connectivity.

• Whilst the off the shelf standard chip solutions are attractive, the issue of cost must be carefully considered for your specific applications. For some high volume and low cost applications it may not be possible to pay the additional cost of the Internet connectivity chip, and the software options may become more attractive. Beware that the balance may shift over time, and what is a cost effective option now may become more costly in the future when your company is considering the next generation of products.

• Devices may be single sourced whereas the investment in developing a TCP/IP software stack will allow “future proofing” of the design solution.

• Another possible situation where a hardware solution may not be necessary or desirable, is when implementing internet connectivity in complex products with powerful microprocessors that have plenty of MIPs (million instructions per second) and system memory to spare such as some automatic test equipment (ATE) and interactive video games. Some of these products already have external communications capabilities, such an Ethernet interface or a built-in modem. In this case, the design engineers may opt for using a software implementation of TCP/IP without introducing any significant changes to the hardware.

• If your application does not demand a full implementation of TCP/IP and require only a modest functionality, it may not be necessary to add the additional cost of a dedicated Internet connectivity chip. Some of the proprietary software TCP/IP stacks for your microcontroller may adequately cover all your requirements.

3.1.1.1 The Connect One iChip Connect One supplies an off the shelf solution in the form of its iChip Internet connectivity IC. It is a more sophisticated product than the S7600A. The iChip COS561AD-S Internet Controller is a peripheral chip that works with the host processor of your product or device. It mediates the connection between the host

of 77

processor and the internet, and is independent of the host processor and operating system used. The designer installs the chip between the host processor and the communications line on the product’s host board, and iChip uses IP commands to run PPP, UDP, TCP/IP, SMTP, POP3 and MIME to connect to the Internet.

The iChip has to UARTs for serial interfacing. One of the UARTs is used to communicate to the with the host processor, whilst the other connects to a communications peripheral, such as a modem or an Ethernet interface. The iChip’s firmware supports a dial-up modem in the range 2400 bps to 56 kbps. It also supports connection to Ethernet LANs and mobile modems. The device includes onboard memory and does not require any additional hardware to implement internet connectivity.

With iChip, there is no need to redesign the basic product with a more powerful processor to run the internet protocols, nor to add extra memory to store the protocols, nor to change the operating system. iChip, and similar internet connectivity peripheral ICs, makes it possible for a manufacturer to utilise most of an existing design. This will certain the time to market for new internet-enabled products, if the additional price of the chip is considered acceptable and their supply is guaranteed.

The chips, which uses 8/16 bit architecture, also has onboard flash memory which is highly suited for the dynamic nature of the internet. The iChip internte controller keeps the internet protocols and configuration separate from the application. It has 512 kbytes of flash memory and 128 kbytes of SRAM (Static Read/Write Memory). New protocols and configuration parameters can be downloaded to the iChip.

Connect One has simplified communications between the device and the application by providing high level command structure. iChip uses the company’s AT+i internet extension to the Hayes AT command set ad the API for communicating with the host processor. In internet mode, the chip invokes high level commands that run the internet protocols (IPs). The iChip then sends commands to dial, log into, authenticate, and sign off from the ISP. The application software bypasses iChip in standard mode, enabling the host processor to work with the communications platform.

3.1.2 Hardware TCP/IP Modules

These Components Off the Shelf (COTS) modules offer a modular solution, similar to the application of Modem modules, in an embedded system. Whilst the systems offer TCP/IP stacks the footprint of the device and the cost of the device will be generally higher than that for a dedicated in-house solution. The COTS solution is therefore suitable for high value, low volume applications. COTS modules are available form several vendors including Comtech and Multitech Systems (USA). In some cases, for example the Comtech µWEB, the Application Programming Interface (API) interface layer allows the customers own application code to reside on the communications module and communicate via simple high level commands such as "call send-email". This eliminates unnecessary cost from duplicated on-board processors.

3.1.3 COTS Overview

The following tables show an overview of manufactures offering dedicated HW and/or SW solutions for embedded networking.

of 77

IMPORTANT NOTE: the following tables report only general consideration mainly referred to a “first user” point of view and not applicable “tout court” to a specific application.

Company Main related product HW SW Link CMX Systems INC RTOS, TCP/IP stack X www.cmx.com Cyan Technology Emb. Processors, RTOS, TCP/IP stack X X www.cyantechnology.com Rabbit Semiconductor Emb. Processors, TCP/IP stack X X www.rabbitsemiconductor.com Zilog Emb. Processors, TCP/IP stack X X www.zilog.com Netsilicon Emb. Processors, RTOS X X www.netsilicon.com Accelerated technologies RTOS, TCP/IP stack X www.atinucleus.com Connect One Network Connectivity Chip X www.connectone.com datalight TCP/IP Stack X www.datalight.com eDevice TCP/IP Stack X www.edevice.com emware Embedded Networking SW server X www.emware.com ipsil Network Connectivity Chip, TCP/IP IP X www.ipsil.com iready TCP/IP IP core X www.iready.com Lantronic Network Connectivity Chip X www.deviceserver.com QNX RTOS, TCP/IP stack X www.qnx.com Ubicom Network Connectivity Processor X www.ubicom.com windriver RTOS, TCP/IP stack X www.windriver.com

PRODUCTS and LINKS TABLE

Company Main related product Time to NRE Design

Costs Total cost of ownership

CMX Systems INC RTOS, TCP/IP stack med med med med Cyan Technology Emb. Processors, RTOS, TCP/IP stack med med med med Rabbit Semiconductor Emb. Processors, TCP/IP stack med low med/low med/low Zilog Emb. Processors, TCP/IP stack med low med/low med/low Netsilicon Emb. Processors, RTOS med med med med Accelerated technologies RTOS, TCP/IP stack high med high high Connect One Network Connectivity Chip low low low low datalight TCP/IP Stack med med med med eDevice TCP/IP Stack med med med med emware Embedded Networking SW server med med med med ipsil Network Connectivity Chip, TCP/IP IP med med/low med med iready TCP/IP IP core high high high high Lantronic Network Connectivity Chip low low low low QNX RTOS, TCP/IP stack high high high high Ubicom Network Connectivity Processor low med/low low low windriver RTOS, TCP/IP stack high high high high

market costs

TIME TO MARKET AND NRE COSTS

of 77

Company Main related product Fucntionalities

Performan ces

headroom flexibility

CMX Systems INC RTOS, TCP/IP stack med med med med Cyan Technology Emb. Processors, RTOS, TCP/IP stack med med med med Rabbit Semiconductor Emb. Processors, TCP/IP stack med low low med/low Zilog Emb. Processors, TCP/IP stack med low low med/low Netsilicon Emb. Processors, RTOS high med med high Accelerated technologies RTOS, TCP/IP stack high med high high Connect One Network Connectivity Chip med low low low datalight TCP/IP Stack med med med med eDevice TCP/IP Stack med med med med emware Embedded Networking SW server med med low med/low ipsil Network Connectivity Chip, TCP/IP IP med med/low low med iready TCP/IP IP core med med/high low med Lantronic Network Connectivity Chip low/med low low low QNX RTOS, TCP/IP stack high high high high Ubicom Network Connectivity Processor med/low med/low low med/low windriver RTOS, TCP/IP stack high high high high

FUNCTIONALITIES AND PERFORMANCES

Company Main related product optimal product volume

test costs design

costs

prove - localisatio

CMX Systems INC RTOS, TCP/IP stack med med/high med/high med/high Cyan Technology Emb. Processors, RTOS, TCP/IP stack med med/high med/high med/high Rabbit Semiconductor Emb. Processors, TCP/IP stack med med med med Zilog Emb. Processors, TCP/IP stack med/high med med med Netsilicon Emb. Processors, RTOS med/low med med med Accelerated technologies RTOS, TCP/IP stack high high high high Connect One Network Connectivity Chip low/med low low low datalight TCP/IP Stack med med med med eDevice TCP/IP Stack med med med med emware Embedded Networking SW server med/high med/high med/high low ipsil Network Connectivity Chip, TCP/IP IP med med/high med/high high iready TCP/IP IP core med/high high high high Lantronic Network Connectivity Chip low/med low low low QNX RTOS, TCP/IP stack high high high med/high Ubicom Network Connectivity Processor any med/low med med/high windriver RTOS, TCP/IP stack high med/high high med/high

maintenance n costs

Costs VS Production Volume

3.1.4 Software TCP/IP Stacks

Many microcontroller silicon suppliers and / or their associated tool vendors now supply TCP/IP protocol stacks that can be integrated into software projects developed using these tools. Commercial tool vendors offer several stacks targeted at a range of dedicated devices. Examples of these products include the Interniche and CMX-MicroNet stacks. The latter is advertised as a low overhead solutions aimed at the 8

of 77

and 16 bit processor application area. Careful evaluation of the stacks are required to ensure compatibility with system level requirements, available memory and processor resources. In addition, careful consideration of the licencing agreements are required to ensure the cost per project and / or per product are evaluated before commitment.

Dedicated Internet communications microcontrollers often provide free stacks. One example is the RabbitCore RCM2200 device. The Development Kit prototyping board for this device includes a Rabbit 2000™ microprocessor with SRAM and flash memory, Ethernet and serial ports, digital I/O and Dynamic C® SE development software (with integrated editor, compiler and debugger) with TCP/IP stack. Similarly the Scenix SX-Stack peripheral modules include the physical interface layer with TCP/IP, which enables the development of embedded Internet products. The SX-Stack protocols are implemented as virtual peripheral software modules that are stored in the on-chip flash / EEPROM on one of the company’s processors. Again careful evaluation of the requirements and capabilities offered by such devices are required; often evaluation board and kits allow such evaluations to be conducted quickly.

As an example of a low-end microcontroller implementation, Microchip has developed a PPP connection to an ISP. The hardware consists of a PIC16C63 linked to an external modem via a serial connection. The software dials the ISP, negotiates a PPP connection, and pings every 30 sec to keep the connection open. The 2 kbytes algorithm includes IP but not TCP, so email, HTTP Web pages, or FTP cannot be used.

3.1.5 Real Time Embedded Operating systems (RTOS)

Using a RTOS that supports TCP/IP is a common way of implementing Internet connectivity. Examples of such RTOS include Neutrino from QNX, embedded Linux, and eCos operating systems. The embedded versions of the TCP/IP embedded stack often eliminates some components from the full PC stack verion, such as forwarding between interfaces, a complete web server and email support. It is thought that embedded applications do not normally need such support. The smaller embedded stack may therefore have limitations on how it can be can be configured and what sockets it can use, although most TCP or UDP applications can run on either stack.

Implementing TCP/IP with RTOS require a powerful processor and expertise in software development for Internet applications. If the existing product already have a RTOS with the necessary spare processor MIPs this may be an attractive solution. However, it is important to pay attention to the software development time and effort, which can add significant cost.

3.1.6 Other Specialised Approaches

For very high volume applications or applications requiring a high level of integration due to other constraints, such as size and component numbers, implementing a hardware solution may require the inclusion of the internet connectivity blocks as part of an application specific integrated circuit (ASIC). This does not necessarily require the development from scratch of all the Internet connectivity blocks to implement them on silicon. IP (Intellectual Property) blocks vendors provide these blocks, including hardware implementations of the full TCP/IP stack, for inclusion into third party ASICs. The iReady internet connectivity core is an example of a TCP/IP IP block.

of 77

Embedded Internet connectivity can also be implemented using a DSP (Digital Signal Processor) chip. An example of a DSP based TCP/IP stack is the SmartStack from eDevice. This stack runs on the Analog Devices AD1218x family of DSPs.

3.2 Gateways and proxy protocols Using TCP/IP may not be the best approach for implementing embedded connectivity in all applications. As discussed earlier, handling the full TCP/IP stack requires memory and processing power. However, the main processor in some applications may be an 8-bit or 16-bit microcontroller with insufficient headroom for a complex stack. Implementing internet connectivity in such applications can be achieved with various options including:

• Using a TCP/IP off the shelf chip. • Adding another processor to implement TCP/IP. • Redesigning the original 8-bit or 16-bit design. All of the above options will add cost, risk and increase the time to market. You should choose one of them if the application justifies that. However in many applications the cost is prohibitive, and the application may only requires the exchange of few messages. Examples of such applications are lighting and temperature control in commercial buildings. In such applications, the cost of a TCP/IP light or thermostat may not be acceptable to most customers. In addition, the messages that are likely to be used to control a light, such as on, off and dim, require few bits, thus making the full TCP/IP connection an overkill. An alternative to a direct connection to the Internet is to use a proxy protocol to communicate between the device and a gateway. The gateway will then translate the messages to TCP/IP and bridge the gap to the Internet. This approach is very appealing for companies, such as manufacturers of consumer appliances, which are very sensitive to the manufacturing costs of their products. Such companies cannot justify upgrading the processor just to add networking, especially if networking is still not one of the main attractions of the consumer. This is the case with white goods, such as washing machines, refrigerators and dishwashers. But these companies may be able to implement a small proxy in their products at a small additional cost. An example of a proxy stack is EMIT (Embedded Internet Micro-Internetworking Technology) from emWare. This stack about 1 kbytes in assembly code and may cost less than 1 Euro per device. The vendor includes in this price a bundled gateway, device software and client-side tools. Proxies cannot be used on their own, but require a gateway device. A gateway can take many forms. It may be a device on the LAN, a service that an ISP (Internet Service Provider) or portal supports, or an implementation on the destination server. At the appropriate stage, the gateway recognises and routes proxy traffic to a proxy server. The proxy server then converts the traffic to TCP/IP and reintroduces into the data stream. A gateway may seem to be an added overhead, but its benefits does not only cover applications where TCP/IP cannot be implemented. In some applications, with full

of 77

TCP/IP support, a gateway may still add enough value to be a rational choice such as in the following examples: • A data channel may use an inexpensive, low bit rate modem or wireless

connection with a bandwidth too narrow to support TCP/IP even if it is implemented on the device. One of the JENET User Experiments utilises an RF link between water usage monitoring devices and a gateway in a building.

• In some applications, such as home networks, several protocols may be in use. These protocols may include TCP/IP, power-line protocols, such as X10, and wireless protocols, such as 802.11, HomeRF, blue tooth or GSM. A gateway can serve as a bridge between all these protocols.

• Even with fully embedded TCP/IP, system management and security functions are still required. These may be best left to the gateway. This will reduce the processing burden of each device.

In general, moving some of the networking load into the gateway, a proxy or a reduced TCP/IP stack can be used, thus lowering the required processor performance at each node. For example, a gateway can implement one firewall for several nodes instead of one for each device on the network. However, gateways cannot be used in all applications. For example, the owners of toys and cameras will want to connect the products directly to their home LANs or ISPs. Therefore, a full TCP/IP is required in such cases. A gateway is not required with direct peer to peer connection. Such a connection may occur when a device dials directly into the server. In such cases TCP?IP is not required to pass information back and forth. The advantage of TCP/IP is that it allows connecting a device into the internet. The device can then be indirectly connected to the server. Therefore, TCP/IP allows access to the device from any access point on the internet, not just a special server. 3.3 Hardware ASIC Solutions The most straightforward approach to implementing Internet connectivity using a hardware solution is to utilise one of few commercially available dedicated integrated circuits (ICs). These devices offer most of the functions of the TCP/IP stack, interfacing with a master processor, external communications and Internet applications such as email and browsing. Several vendors provide Internet connectivity ICs including those from Connect One and Seiko Instruments. More details on some of these devices are provided in section 3.1 above. This section deals with more specific ASIC stack options. For very high volume applications or applications requiring a high level of integration due to other constraints, such as size and component numbers, implementing a hardware solution may require the inclusion of the internet connectivity blocks as part of an application specific integrated circuit (ASIC). This does not necessarily require the development from scratch of all the Internet connectivity blocks to implement them on silicon. IP (Intellectual Property) blocks vendors provide these blocks, including hardware implementations of the full TCP/IP stack, for inclusion into third party ASICs. The iReady Internet connectivity core is an example of a TCP/IP IP

of 77

block. More details of this core and examples of its implementation are described in section 2.2.1. Hardware options can provide very attractive solutions for many classes of users who are interested in implementing embedded Internet connectivity in their next product, or those who are interesting in adding this feature to existing products. However, a hardware solution may present disadvantages in some applications. The following points addresses some of the issues associated with the hardware implementation of Internet connectivity:

For those applications which involve ASIC development, the use of an IP core for TCP/IP is not mandatory. It is possible to implement the ASIC with a microprocessor core, by software TCP/IP stack to implement Internet connectivity. Of course, this effectively becomes a software solution with all the associated software development requirements and risks. Therefore, when time to market is critical utilising an IP block is the most logical approach as long as costs are not prohibitive.

3.3.1 iReady core iReady produced the i-1000 core for designers to implement embedded internet connectivity in silicon as part of an ASIC. This means that the core can be used as part of an integrated solution instead of buying an off the shelf chip or using a software implementation on a powerful processor. The i-1000 internet tuner is a fully configurable, embeddable design core that enables you to add internet connectivity to any silicon design. The core is available as tested Verilog HDL (Hardware Description Language) RTL (Register Transfer Level) modules. The i-1000 suits a range of cost and power sensitive Internet designs for applications including mobile phones, PDAs (Personal Digital Assistants), digital cameras and electronic toys. In general, ASIC implementations using this type of core consume less power than general purpose microprocessor implementations. The i-1000 Internet tuner core supports a microprocessor interface through the iReady iAP register set. This makes Internet designs portable and independent of the selected processor and the operating system. The i-1000 features can be accessed with a C language API (Application Programming Interface). The Internet tuner cores require between 40,000 and as high as 225,000 gates depending on the transport method and applications included. It is thought that full Internet capability can be achieved with 120,000 gates. With 225,000 gates it is possible to include Ethernet MAC (Media Access Controller) plus additional applications. The Internet tuner consists of modular engines that can process protocols such as TCP, IP, PPP, UDP, HTTP, HTML, SMTP, POP3, IMPAP4, and image files, such as JPEG. These modules are available as in Veriolg, and the designer can include any of them in the design of the ASIC. A configuration program then automatically generates the RTL code to produce the Internet system on a chip. The company also supplies an evaluation kit for the i-1000 core, which consists of hardware and software components to demonstrate the core’s functions. The kit includes a PC plug-in board and a user interface program to enable the user to try the internet tuner’s web browsing and email features. iReady provides C source code and documentation for its web, email and socket APIs.

of 77

3.4 Software solutions

3.4.1 Real Time Operating Systems (RTOS) Using a RTOS that supports TCP/IP is a common way of implementing internet connectivity. An example of such RTOS is Neutrino from QNX, which gas TCP/IP modules for a full or an embedded stack. The embedded stack eliminates some components, such as forwarding between interfaces, a complete web server and email support. It is thought that embedded applications do not normally need such support. The smaller embedded stack also limits the how it can be can be configured and what sockets it can use, although most TCP or UDP applications can run on either stack. The stack implementation offered by QNX is modular and therefore, it can be dynamically loaded when necessary for memory constrained products. In addition Neutrino enables the system to be updated in pieces because it does not have binaries linked to the kernel. This allows for remote reprogramming or upgrading without rebooting. Implementing TCP/IP with RTOS require a powerful processor and expertise in software development for Internet applications. If the existing product already has a RTOS, it is worth with the necessary spare processor MIPs, this may be a variable solution. However, it is important to pay attention to the software development time and effort, which can add significant cost.

3.4.2 The gateway approach With the gateway approach of section 2.1, it is possible to work with proprietary protocols. This approach allows the use of general purpose microcontrollers and does not require specialised ICs. The web server resides as software in a microprocessor or microcontroller. The TCP/IP and HTTP reside in a gateway PC that bridges the proprietary protocols to TCP/IP. Access to the gateway can be through RS232, RS485 or Ethernet physical link. This approach has been adopted by emWare which offers an internet-networking software, the EMIT (embedded-micro-interface technology) architecture. The architecture enables 8 and 16 bit processors to connect to the Internet without requiring a RTOS or TC/IP stack at the device. The EMIT architecture is supported by many of the major semiconductor manufacturers, such as Philips, Hitachi and Atmel, who formed the ETI (embed-the-internet) consortium. The EMIT architecture includes several components includes several components. The emMicro component is 1 kbytes micro web server that allows a web browser to view and control variables and controllers in the embedded device by serving microtags. Microtags are small data pakets that occupy 10 bytes to 2 kbytes of memory and define device controls. Typically, emMicro requires 1 kbytes of ROM and 32 bytes of RAM with an on-chip communications port, such as RS232 or RS485. The emGateway product provides a link between light-weight device networks and large, high performance networks that can include the internet. The emManager product interfaces between the browser at the desktop and emMicro at the device. The EMIT arcitecture supports a wide range of processors from most vendors including the 8051 architecture and the PIC16C7xx.

of 77

EmWare provides EMIT software development tools that allows the implementation of emWare technology into 8 and 16 bit embedded devices. Software development kits are also available from various ETI partners and are low cost. However, the product licence fee from emWare can be quite high and covers only a single product.

3.4.3 Virtual peripherals The concept of virtual peripherals is promoted by Scenix. Virtual peripherals modules are basically software equivalents of microprocessor peripheral hardware. For example, interface modules from the Scenix virtual peripheral library include UART, I2C and IrDA (Infrared Data Association) interfaces. Implementing and peripheral will consume a proportion of the Scenix processor’s MIPs. The processors are fast RISC processors. The SX-Stack peripheral modules can communicate with any web browser on the internet and can also receive and transmit email. The SX-Stack includes the physical interface layer with TCP/IP, which enables the development of embedded Internet devices without external physical access chips or a gateway PC. The SX-Stack protocols are implemented as virtual peripheral software modules that are stored in the on-chip flash/EEPROM on one of the company’s processors, which can deliver 50 or 75 MIPs. There two configurations of the SX-Stack. These are the iSX web server and the eSX email appliance. These configurations can be implemented individually or combined in the same processor.

3.4.4 DSP based stacks Embedded Internet connectivity can be implemented using a DSP (Digital Signal Processor) chip. DSP-based stacks are commercially available today. They capitalise on the increasingly powerful DSPs that are appearing on regular basis. An example of a DSP based TCP/IP stack is the SmartStack from eDevice. This stack runs on the Analog Devices AD1218x family of DSPs. Using the power of DSPs opens many possibilities such as: • The modem software and the TCP/IP stack can be put into the same chip.

However, if only connectivity is required, a less powerful member of the AD1218x family can be selected to reduce cost.

• Choosing a more powerful member of the AS1218x family with a higher clock rate and larger memory will allow other functions to be implemented alongside TCP/IP. For example, the extra MIPs can be used to play back MP3 files or voice messages which have been downloaded to the device.

The cost of the SmartStack/AD1218x chip set starts at about 20 Euro including the analogue front-end chip. It is expected that future versions of the chip set will include different connectivity options by integrating Ethernet or wireless MACs ( Media Access Controllers) using an external physical layer device. Therefore, the chip set and the software can be used to serve different connectivity infrastructures. Only the interface chip needs to be changed.

of 77

3.4.5 Microcontroller based stacks There have been few TCP/IP proprietary implementations targeted at 8 and 16 bit microcontrollers. In general, these implementations tend to be limited and do not offer all the functions of TCP/IP or higher level applications due to the constraints of processing power and memory requirements. Many of these implementations take some shortcuts and require careful consideration before adopting them. At the end of the day, it is very much dependent on your application. If proprietary microcontroller based stacks limited with their limited functionality can provide with all the requirements for your application, then there is no reason why they should not be utilised. As an example of microcontroller implementations, Microchip has developed a PPP connection to an ISP. The hardware consists of a PIC16C63 linked to an external modem via a serial connection. The software dials the ISP, negotiates a PPP connection, and pings every 30 sec to keep the connection open. The 2 kbytes algorithm includes IP but not TCP, so email, HTTP Web pages, or FTP cannot be used.

3.4.6 Modules and boards Prototype and demonstration boards are available for the development of microcontroller-based projects. They consist of the target microcontroller device, some peripheral devices (e.g. memory, displays, switches, serial interface, etc) and, in the case of the prototype boards, an area to add further components. The application can be built up on the board and when it meets the specification, a custom printed circuit board can be designed. This process reduces development time, and eases the verification and debugging process. A typical example of an Internet demonstration board is available from Microchip, the PICDEM.net. This board allows the developer to evaluate different TCP/IP stack solutions. This board includes the PIC16F877 microcontroller together with the TCP/IP firmware required to implement the TCP/IP stack. An Ethernet interface is provided, to allow the board to connect to a twisted pair network hub (via a RJ45 connection). An Ethernet transceiver is provided on the board, and an in-circuit debugger can be connected to monitor and verify the board’s execution. The PIC16F877 is in-circuit programmable, which also greatly reduces the development cycle time. A LCD display is included for debug and status messages to be displayed. Another example is the ZiLOG eZ80190 Webserver Evaluation Kit, which has a eZ80 microprocessor, with both SRAM and Flash memory, Ethernet interface, serial interfaces and expansion headers. The board interfaces to the ZiLOG developer studio, which includes an integrated GUI, Compiler and debug environment (see appendix). RabbitCore RCM2200 Development Kit prototyping board includes a Rabbit 2000™ microprocessor with SRAM and flash memory, Ethernet and serial ports, digital I/O and Dynamic C® SE development software (with integrated editor, compiler and debugger) with TCP/IP stack.

of 77

3.5 Which approach? The solutions outlined in section 2 illustrated the range of approaches for implementing embedded internet connectivity. Deciding whether to go with hardware or software, full stack or proxy requires consideration of several issues and an understanding of: • How your device will connect to the internet. • What kind of information it needs to pass and receive. • How easily can you integrate the software into your own design. • How easily can you integrate one or more chips to the existing design. • Does adding a TCP/IP stack require a complete redesign of your product? In general, for applications with a powerful processor, supporting Internet connectivity requires adding a software stack and a network interface. On the other hand, if you are short of memory and your processor does not have many MIPs to spare, using a proxy protocol with a gateway or implementing the TCP/IP stack as hardware is probably a better approach. There are always other factors to consider including cost, time to market, risk and design maintenance requirements. Another very important factor is the level of expertise at your company in hardware and software design, especially in relation to networking.

3.5.1 Memory and processor requirements For a full implementation of TCP/IP embedded internet connectivity, the product’s processor should be a powerful 16-bit or 32-bit processor to ensure that there are enough MIPs available to cover all the stack and application requirements. If the processor does not have enough MIPs to run the internet protocols, a new processor must be added. The memory requirements can be high for such a full implementation and it may include: • The basic TCP/IP stack may use between 35 and 60 Kbytes of memory depending

on whether or not the complete stack is supported from PPP (Point-to-Point Protocol) on the physical layer through the TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) on the transport layer of the OSI (Open System Interconnection) seven layer networking model.

• On top of the TC/IP stack, there may be email protocols to support, including SMTP (Simple Mail Transfer Protocol) for sending to a mail server and POP3 (Post Office Protocol 3) for receiving from a mail server. These protocols can add an extra 5 to 15 Kbytes depending on whether or not they are both supported.

• Supporting HTTP (Hypertext Transfer Protocol), the web client, requires an extra 10 to 20 Kbytes.

Therefore, adding full internet connectivity can increase the memory requirements of the application by 70 to 135 Kbytes. This excludes the memory requirements of the real-time operating system and additional management functions, which may require another 55 Kbytes.

of 77

In general, to enable full connectivity the device must have non-volatile memory, such flash or EEPROM. Non-volatile memory is required for the following reasons: • Because the internet is a dynamic medium, it may be implemented differently

from server to server. Therefore, it may be necessary to modify the protocols to match those supported by a particular ISP.

• Dial-up parameters to an ISP may change and need to be updated. If a device does not have non-volatile memory these updates cannot be stored in the device. Therefore, the device may not be able to connect to the internet.

• The device must be programmed to dial up the ISP, log on, authenticate the user account and password, send and receive email or a web page and log off. These commands must be written into the application and stored with the relevant internet protocols in the device’s memory. If the device does not have enough memory to store the internet protocols and configuration parameters, additional memory must be designed in. Flash memory that can be updated in the field is preferable.

•

3.5.2 Development time and risk If a new processor is added, a new development environment may be necessary. New development tools and kits may be required for programming the processor during the development stage. It may be also necessary to have a new RTOS to go with the new processor. This may add significant time, effort and cost due to the learning curve. Once software and hardware development is completed, the system needs to be integrated, debugged, tested, deployed in alpha and beta sites, revised, released in production version, and maintained. The whole development process is therefore, complex, and may take several months or a year to complete. This delay in time to market can have a significant negative impact on the success of the product and its market potential. Therefore, there are serious financial, marketing and technological risks when dealing with internet connectivity, especially if you are a first user. Additional risks include budget overruns, development time delays, incorrectly implementing the Internet protocols and being unable to update these protocols.

3.5.3 Cost implications The cost analysis of different approaches to implementing internet connectivity are presented in this section. The figures shown here were provided by a vendor of an internet connectivity chip. Therefore, they may be biased to its solution. However, the analysis methodology is what matters here, and the figures has to be worked out by the designer because they change all the time as the cost of technology changes and new devices and development tools are introduced into the market. The analysis here is about upgrading an existing design to include full Internet capability. In this case study, the following assumptions are made: • The current design uses an 8 bit or low-end 16 bit processor with built-in program

memory, no external flash memory, limited RAM and low-speed modem. Upgrading requires a more powerful processor, faster modem and more memory.

of 77

• Software licences are non-transferable, one-time, royalty-free, single use licences. • A new CPU environment is required due to the change of processor. Table 1 lists the costs of the existing system and the software based upgraded system in volumes of 5k and 10k units. The figures have been converted from dollars to Euros and are approximate. As stated earlier, it is assumed that in this application full internet connectivity is required with many applications, such as email. The entries in the table shows all the cost elements that must be taken into account when considering a full upgrade of an existing product to one with embedded internet connectivity.

Full in-house software based design costs (Euros)

Current design costs (Euros) 5k units 10k units

Hardware Processor 4 8 8 Flash (512 kbytes) 0 6 6 RAM (128 kbytes) 2 4 4 Modem 6 10 10

Total Hardware 12 28 28 Software (licences amortised per unit)

RTOS @ 20k Euros 0 4 2 PPP, TCP/IP, SMTP, POP3, HTTP server @ 55k Euros 0 11 5.50

Total Software 0 15 7.50 Total Software & Hardware 12 43 35.50 Software development labour and tools costs (amortised per unit)

Development costs 0 48 24 Ongoing software maintenance 0 10 5

New processor development tools 0 6 3

Total software development 0 64 32 Overall Total 12 107 67.50

Table 1 – Cost analysis of the existing design and the in-house software solution for volumes of 5k and 10k units.

On the hardware side of table 1, the figures show that upgrading the processor and adding the required RAM and flash memory can almost double the cost of the hardware. The faster modem will also add to the cost, but that will be required in any dial-up implementation. The cost of the software licences can make a significant to the overall product cost. In this case, the additional internet related software includes the RTOS, the stack and the internet applications. Of course, these are one off payments and can be amortised over the production volume. The cost per unit can be a lot more than that of the hardware.

of 77

Most software vendors tend to offer their licences for one product only. Developing another product requires purchasing another licence or extending the existing one. Important cost elements, which are sometimes ignored by many companies when making cost comparisons, are the development and maintenance costs of the software. Those include the price of the development tools, if a new processor is used. The cost of the new processor development tools depends on the number of seats your company requires. The labour cost associated with software development can be divided into two parts. The first is related to the development effort of the embedded internet applications including using the RTOS and the TCP/IP stack. This is the most costly part because a project of this complexity can take many months, and possible a year, to complete. The second part is the ongoing software maintenance cost, which is required to update your software and fix bugs. Considering the figures of table 1, it is worth noting that the development costs associated with the software can form a significant part of the overall product cost, even after amortisation. In the example here, the software development forms approximately 50% of the overall cost element. Therefore, before embarking on internet connectivity project it is important to conduct a thorough cost analysis and examine all alternatives.


Design costs using iChip (Euros)

5k units 10k units 5k units 10k units Hardware

Processor 8 8 4 4 Flash (512 kbytes) 6 6 0 0 RAM (128 kbytes) 4 4 0 0 Modem 10 10 10 10 iChip 0 0 25 20

Total Hardware 28 28 39 34 Software (licences amortised per unit)

RTOS @ 20k Euros 4 2 0 0 PPP, TCP/IP, SMTP, POP3, HTTP server @ 55k Euros 11 5.50 0 0

Total Software 15 7.50 0 0 Total Software & Hardware 43 35.50 39 34 Software development labour and tools costs (amortised per unit)

Development costs 48 24 2 1 Ongoing software maintenance 10 5 0 0 New processor development tools 6 3 0 0

Total software development 64 32 2 1 Overall Total 107 67.50 41 35

Table 2 – Cost analysis of in-house software solution and an iChip based design for volumes of 5k and 10k units.

Table 2 compares the cost of the software implementation versus a pure hardware implementation using the iChip COS561AD-S processor described in section 2.2.3.

of 77

Since iChip can be used as a peripheral chip it does not require special interfacing hardware with the existing host processor. In addition, iChip has all the necessary memory. Therefore, the additional hardware costs are only related to the cost of iChip itself. Of course, you still need a fast modem. Where the hardware solution wins is on the cost of the software licenses and the development effort and time. There are no licence fees for the embedded internet software, nor there is a need for new processor development tools. In addition, the software development effort with iChip is only related to the applications in the host processor Therefore, adding internet connectivity can be more cost effective if a an off the shelf internet processor chip is used for the modest volumes of 5k and 10k units. The grand total figures of table 2 clearly illustrates the cost advantage of the hardware solution, even if some of the figures may be exaggerated. The contribution of the fixed software licences and development costs per unit become smaller as the volume increases. The question is, where is point where the hardware solution become more expensive? Table 3 show a cost comparison of the two solutions for volumes of 50k and 100k units. Clearly, the unit cost for both solutions become very close. For much higher volumes, the software solution will eventually give a lower unit cost and become more competitive. However, the figures in tables 2 and 3 do not quantify risk or the potential for delays resulting in lost market opportunities. In addition, for a new user of the technology there is a steep learning curve which may add to the cost. Therefore, the hardware solution can cushion against these effects at least for your first embedded internet product. As experience is gained in the technology, it is possible to begin exploring more in-house solutions, such as the full software implementation.

of 77


Design costs using iChip (Euros)

50k units 100k units 50k units 100k units Hardware

Processor 7 6 3.50 3 Flash (512 kbytes) 5 4 0 0 RAM (128 kbytes) 3.50 3 0 0 Modem 9 8 9 8 iChip 0 0 15 11

Total Hardware 24.50 21 27.50 22 Software (licences amortised per unit)

RTOS @ 20k Euros 0.40 0.20 0 0 PPP, TCP/IP, SMTP, POP3, HTTP server @ 55k Euros 1.10 0.55 0 0

Total Software 1.50 0.75 0 0 Total Software & Hardware 26 21.75 27.50 22 Software development labour and tools costs (amortised per unit)

Development costs 4.80 2.40 0.20 0.10 Ongoing software maintenance 1 0.50 0 0 New processor development tools 0.60 0.30 0 0

Total software development 6.40 3.20 0.20 0.10 Overall Total 32.40 24.95 27.70 22.10

Table 3 – Cost analysis of in-house software solution and an iChip based design for volumes of 50k and 100k units.

3.5.4 Conclusions The example described in section 3 of these document covered an extreme case, where a full embedded internet connectivity solution with all protocol options are required. The two possible solution, which were presented above showed that there are many factors to consider including cost, expertise, risk and time to market. In addition, your application itself may dictate the nature of the solution. Having a powerful processor with spare MIPs, and existing RTOS and a lot of unused external memory will probably make the software option attractive. In most applications the likelihood is that you do not need all the functions offered by internet connectivity. It is not expected that all embedded internet applications need to serve web pages or send email. Therefore, some of the implementation approaches described in this document may offer suitable and cost effective solutions, such as a partial TCP/IP The decision about a full implementation and a proxy/bridge combination is very important because you may find that your individual products can remain very low cost, and you can implement your bridge with a standard PC.

of 77

However, as it is likely that more embedded connectivity tools, boards, chips and modules will appear in the market by the time you have completed reading this document, you need to do your own search and cost calculations.

3.5.5 Selecting an Embedded Internet Development and Evaluation System A number of vendors, such as Connect One, Rabbit, and Zilog, now provide ‘easy to start’ evaluation systems to aid companies in the adoption of embedded TCP/IP networking. The acquisition of these evaluation systems provide an important step in the development process for embedded systems, and a careful consideration of the development and evaluation systems is necessary. The cost of many embedded Internet stack devices is now similar, and the selection of the appropriate embedded networking solution will require an assessment of general market adoption of this device (to ensure longevity of supply), development time required to become productive in the use of the device and to perform more complex networking actions, and assessments of technical support including on-line assistance, web forums or bespoke training courses. The evaluation of commercial adoption of solutions is not undertaken in this document because of the moving nature of the supply industry, but suggestions as to issues to address in evaluating development environments and subsequent support are provided below. Amongst the considerations to be addressed are:

• Physical connectivity: Issues to consider include does the evaluation board provide an Ethernet connection (including cable accessories), a modem, or both and what is the interface to the host development PC. If the purpose of the final product is to interface through a commercial ISP (Internet Service Provider) then the provision of a modem that can connect via a serial port to the development system, together with an API (application programming interface) that allows the user to quickly become connected to the ISP. Similarly, the additional, often modest, cost of purchasing a development system which interfaces to the development PC via a high bandwidth connection (such as USB) can be compensated for by the time saved in downloading new versions of test programs when an engineer encounters a problem.

• Development facilities: The vendor may supply a range of different evaluation boards ranging from the basic introduction level to the advanced. Often the differences may lie in the range of application libraries provided; more advanced development tools may provide a wider range of application examples and start up code examples or a wider range of debugging facilities. The investment in the higher level tools may be justified in terms of programmer productivity if the end application involves use of anything but the more basic TCP/IP functions (such as PPP -point to point protocols).

• Evaluation board implementation: The purchase of a flash based evaluation system may have advantages over basic RAM based boards if longer term evaluations are to be performed when software or hardware crashes may require the code to be downloaded again.

• Supporting Documentation: The availability of a ‘getting started’ manual or text file is an important facility in the quick application of the selected device or stack. The provision of documented source code applications in the supporting

of 77

documentation text can be an important time saving feature. Amongst the issues to be considered with regard to source code availability is whether source code examples are provided for the main functions that are likely to be encountered in the end application. For example are source code files provided to demonstrate how an email can be transmitted and how FTP (file transfer protocol) facilities can be implemented. Development solutions with a wide range of such application programs will in general be easier to use. More subtle issues may often arise (for example, when data type of file length changes are implemented) and then reference to a supporting manual is essential. These documents can be very lengthy and the organisation of the information in the manual needs to be clear. Confirm that, or if possible review, the documentation to determine the prior knowledge level that it assumes is consistent with the development engineer’s actual experience. For example some development systems may assume no prior knowledge of TCP/IP or networking whilst others may assume a more advanced user.

• Test Facilities: Some applications may require test facilities to be established, for example a limited server facility to test the download of a file from an ISP site. The development of such a facility could be a challenging task at first, and any test utilities provided by the evaluation system to first get working could be beneficial. Other, more limited test facilities may involve the provision of an LCD display on the evaluation board to display progress or debug messages may also be an useful facility.

• Physical media: Some vendors may provide a protocol driver to enable transmission over other physical media beyond Ethernet, for example the 802.11 interface. If the end application requires connectivity over such physical media then the appropriate selection of the evaluation or development tool can save important development time.

The availability of technical support is also a major issue. Some companies provide FAQ sections to support the use of their development tools, but these often are limited in scope and usefulness, and may be vendor driven. An user web forum can often provide useful information from other users and can be viewed before purchase of the tools.

The availability of seminars or training courses operated on the selected device is an important aspect of the support provided by vendors. The usefulness of the training provided is amplified if the training course uses the actual development tools as a hands-on experience.

of 77

4. Physical Layer Implementations This section describes some of the alternative physical layer implementation solutions that can be considered to provide both the data transfer medium for information to be forwarded via the Internet, including an introduction to wireless links including WLAN (wireless local area networks). The information is not designed to be comprehensive, but to act as an introduction to the options available. 4.1 Introduction

The are several network physical connection possibilities, including:

• Dial-up modem (PSTN, ISDN, ADSL, GSM, GPRS, ….),

• Ethernet link (but there are 20 Ethernet physical layer media specifications),

• Power line link (but there are many different standard, consolidated or emerging),

• Wireless links (Wireless LAN IEEE 802.11b, IEEE 802.11a , HiperLAN1, HiperLAN2, Home RF, Bluetooth, ..?),

• or by using a traditional industrial media (RS485, RS232, …).

4.2 System Design Consideration

4.2.1 Product requirements

Most embedded product are cost sensitive, and this constraint requires a deep performance versus cost analysis. The bill of material (BOM) cost of an embedded product with Ethernet connectivity is typically from 30 to 110 Euro, although this may decrease down to 15 Euro in a couple of years. Normally in a traditional embedded design the recognized parameters are: product functional and technical requirements, environmental constraints (in term of temperature range, elemental exposure and so on) and production costs. In a TCP/IP networked product other “hidden” parameters are relevant; first of all time-to-market that can be dramatically reduced with a design approach that uses a commercial (library or RTOS) TCP/IP stack or a commercial “internet chipset”. This approach probably increase the raw cost of the product but if we include in the costs also the development costs of a full optimized- full custom TCP/IP stack, the cost for testing and validation and maintenance, if the expected production is for thousand pieces then the “real” cost is higher for the full-custom unit.

Other parameters to be recognized are human interaction with the unit, remote update capability (and its frequency), maximum latency toleration, real data traffic in each node of the network.

The last two are critical issues to be fixed during the system design phase. As an example, we suppose to define a network with ten devices connected using a 10BaseT Ethernet. The 10BaseT is a 10 Megabit connection but the real (sustained) throughput in a real application is lower. To estimate 1 Megabit (derived from 10Megabit/Number of nodes) is dangerous: if 10 nodes are trying to exchange data in the same time the net throughput can be much lower than 1 Megabit because a relevant part of time is wasted to detect and resolve conflicts (Ethernet is a standard CD, Conflict Detect, and not CA, Conflict Avoid). If latency is important in that system and is not possible to implement a master-slave socket protocol (the network

of 77

server request data to one node at a time), probably the best solution is to have a 100BaseT link (100 Megabit on the physical channel). On the opposite side, if the data network is composed of a large number of nodes with a reduced number of parameters to be controlled for each unit, then the use of a full TCP/IP approach involves an unacceptable overhead. Probably the best solution is to aggregate the basic unit in clusters breaking the TCP/IP with an embedded gateway. The link between the gateway and the node cluster can use a low-level custom protocol, while the link between the gateway and the network use TCP/IP.

4.2.2 Network topology

Many factors have an influence on the definition of network topology and on the selection of the physical link. These include minimum sustained throughput, latency, the presence of existing wires, the possibility of introduce new wires in the plant, environment (e.g. the noise in an industrial line suggests to avoid a power-line connection), and so on.

In the following chapters we will examine some key technologies for the network physical link.

4.2.2.1 Non Local network connection. If the embedded network requires an access to an external server (e.g. to an ISP – Internet Service Provider), is important to select the right connection.

Consolidated wired technologies for the Internet connection are PSTN analog modem, ISDN and ADSL. Consumer mobile device are the GSM (9600 bit) and GPRS (64Kbit maximum). 3G-GSM terminal will be available during 2002 (..?..).

Another existing connection is the satellite link but is too expensive for “normal” application. For the home-internet market is now available a mixed solution (called DBS Direct Broadcast Satellite) having an incoming satellite link (download) with a speed in excess of 45Mps, and an outgoing (upload) link based on a traditional telephone connection. We don’t examine this solution because it is not adequate to the embedded market.

An emerging technology for the broadband access is the power networks. The strengths of this technology, that use the public power grid as fast information carrier, are: it is the most extensive wired network in the world, power lines carry signals for long distance without requiring regeneration, the available band for digital signal transmission is very-very large, there is no topology limitation. The main weakness of this technology is that it is still in the development stage.

ADSL The increased request of fast data connection has pushed telecommunication companies to deploy a class of technologies known as DSL (Digital Subscriber Lines). These technologies (depending on their exact type, ADSL, HDSL, SDSL and VDSL) have a bit rate up to 51 Mbps. The most diffuse is the ADSL (Asymmetric DSL), that have three information channels: a plain old telephone channel for voice, an upstream channel up to 1 Mbps, a downstream channel up to 8 Mbps. Telecommunication companies have a wide range of commercial offers for home and business users.

Due to its asymmetric nature this technology is suitable for application in which the added value of the service is in the downstream (internet connection, video on

of 77

demand, internet radio, and so on), while is not suitable in application in which the ratio between the upstream and the downstream is 1 (e.g. high definition video conference).

From an embedded point of view strengths are broadband, the capability of to implement a static connection, the easy implementation of a dynamic web-on-demand service. Main weakness is the HW cost (due not only to the physical connection but also to the processor cost increase).

ISDN ISDN (Integrated Service Digital Network) is a well known and consolidated technology. Currently it is widely adopted and has two main variants: Basic Rate and Primary Rate.

Basic Rate, delivered over the same single twisted pair used for Old Telephone Services, provides two 64Kbps channels (B type) and one 16Kbps channel (D type). This connection is normally offered for home networks and small business.

Primary rate, delivered over two sets of twisted pair telephone lines, provides one 64Kbps D channels, plus several 64Kbps B channel (23 in US and 30 in Europe). The total rate is 1.544 Mbps in US and 2.048 Mbps in Europe.

The ISDN channel is a “natural” alternative to DSL for many “low” bit rate services. Due to its wide utilisation many “flat-like” connection services are now available also for home network. This services use the D voice channel (always connected) to provide also data traffic (connecting the other 2 B channels only for peak request).

This solution for the embedded market is suitable for low quality video and audio broadcasting application. The availability of digital service (ex: caller identification) makes easier to implement web-on-demand services.

GMS and GPRS GSM deliver a 9600 bps data channel while GPRS, an intermediate step between GSM and 3G standards, has a 64 Kbps data channel (but the real channel available for user depends from the telecommunication companies and is expected to be no more than 19.2Kbps).

The GSM, or GPRS, solution for remote connection is suitable for application when a PSTN line is not available. The PSTN solution, if available, is normally cheaper than a GSM solution. For the GSM connection is better to avoid the use of consumer GSM telephones because the consumer market changes too fast for industrial application and the maintenance costs of an industrial solution based on a consumer terminal can be unacceptable.

The cost of an industrial OEM GSM module is from 140 to 300 USD (depending on quantities).

PSTN Analog

The availability of a wide range of low cost analog modems makes the PSTN technology the most suitable for low cost embedded products.

Currently the market offers 14.4 Kbps chipsets for 15 USD (1K units) and 56 Kbps complete modems for 60 USD.

of 77

There are other very low cost 2400 bps modem chipsets for 7 USD. These modems are the best solution if the remote unit wants to transmit only a few data bytes (e.g. the state of sensors) not only because the HW is less expensive but also because the connection time (if compared with a 56 Kbps PSTN modem) is very short and the call cost is reduced.

The main problem is that normally ISPs (Internet Service Providers) don’t support these low speed connections and if the ISP itself is not involved in the business is very difficult to obtain a connection lower than 14.4 Kbps.

The solution could be the installation of custom servers but this is a problem if the target units are located in a large area.

4.2.2.2 Local network topology. During the definition of a local network for an embedded system main parameters to be recognized are: minimum sustained bit rate, maximum latency, costs, capability to add new wires to the plant, structural and electrical constraints (e.g. the presence of a wall can be an obstacle for a wire-less connection while a noisy power grid is not suitable for a power line connection).

Some examples of errors due to a not deep enough analysis of these parameters are described in the following chapters.

Trying to define a trivial rule to select one solution we obtain the following theorem:

“if you add new wires to the plant you can obtain the best cost/performance ratio of the embedded HW increasing the installation costs. Using existing wires you increase the minimum cost of the HW reducing installation costs. Using a wire less connection the cost / performance ratio is the worst while the installation cost is the best”.

4.2.2.3 Local Network Adding New Wires.

4.2.2.3.1 ETHERNET Ethernet is one of the most famous standards for network connection, developed many years ago by DEC, Intel and Xerox. The IEEE official standard is IEEE 802.3.

This standard uses the CSMA/CD access method to manage multiple access on the same media. CSMA/CD stands for Carrier Sense Multiple Access with Collision Detect. Using this access method a device can send data at any time without limitations following a simple rule: if there is a carrier in the media (traffic from other agents), a device wait until the line is free. When the line is free the device sends its data immediately. This causes a large number of conflict if many devices are waiting to transmit data. When a conflict is detected devices return in wait state, each for a random time (if the waiting time is the same for all device the media is locked).

This simple method allows the sharing of the same media carrier by many devices but contains an hidden issue. The real sustained bit rate depends not only on the maximum carrier frequency of the media (Ethernet has media specification from 1Mbps to 1Gbps) but also on the number of nodes that are trying to send data in the same time and the relationship between the number of nodes and the real sustained bit rate is not linear .

As an example we suppose to define a network with ten devices connected using a 10BaseT Ethernet (10 Megabit connection). Is dangerous to estimate 1 Mbps of sustained bit rate (derived from 10Megabit/Number of nodes): if 10 nodes are trying

of 77

to exchange data in the same time the net throughput can be lower than 1Mbps because a relevant part of time is wasted to detect and resolve conflicts.

If the embedded Ethernet network shares the physical carrier with another system (e.g. a PC office network), the real sustained bit rate is unknown and it is possible to estimate it only with a statistical approach.

The success of Ethernet is mainly due to its scalability on different media (coaxial, 2 twisted pair cable, optical fiber and others) with different performances (from 1 Mbps up to 1 Gbps) and its low costs.

The most famous Ethernet implementation are the 10Base2 (IEEE 802.3a), 10Mbps half duplex on 50 ohm coaxial cable, the 10BaseT (IEEE 802.3i), 10Mbps full duplex on 2 pairs of 100 ohm cat 3 unshielded cable, and 100BaseTX (IEEE 802.3u), 100Mbps full duplex on 2 pairs of 100 ohm cat 5 unshielded cable.

The first one (10Base2) is a single bus network topology, the other two use a star topology. Many commercial Ethernet hubs, routers and switches are available to implement any kind of star network with different performances.

Costs are very low: a 10BaseT bill of material costs from 6.3 to 10 USD (including chipset, transformer, RJ45 connector and passive components) for 5000pieces. A 100BaseTX MAC (the largest silicon part of a 100Mbps interface) is actually inserted as standard peripheral in many processor, or is available as HW or SW macro for any kind of FPGA. The external component costs to implement this interface are close to 5.3 USD (10K pieces), including physical interface with MII interface, transformer, RJ45 connector and passive components.

The following tables detail the available Ethernet standards: Ethernet 1 to 10 Mbps standards

Standard

IEEE

Data

rate

Medium

Topology

Max. cable length

Half Duplex Full Duplex

1 Base5 802.3e 1Mb/s Two pairs of twisted telephone cable

Star 250M N/A

10 Base5 802.3 10Mb/s Single 50-ohm coaxial cable (thick Ethernet)

Bus 500M N/A

10 Base2 802.3a 10Mb/s Single 50-ohm RG 58 coaxial cable (thin Ethernet)

Bus 185M N/A

10Broad36 802.3b 10Mb/s Single 75-ohm CATV broadband cable

Bus 1800M N/A

10 Base-T 802.3i 10Mb/s Two pairs of 100- ohm Category 3 or better UTP cable

Star 100M 100M

10Base-FL 802.3j 10Mb/s Two optical Fibers Star 2000M >2000M

10Base-FB 802.3j 10Mb/s Two Optical Fibers Star 2000M N/A

10Base-FP 802.3j 10Mb/s Two Optical Fibers Star 1000M N/A

of 77

Ethernet 100 Mbps standards

Standard IEEE Data

rate

Medium Topology Max. cable length


100 Base-TX

802.3u 100Mb/s Two pairs of 100-ohm Category 5 UTP cable

Star 100M 100M

100Base-FX 802.3u 100Mb/s Two Optical Fibers Star 412M 2000M

100Base-T4 802.3u 100Mb/s Four pairs of 100-ohm Category 3 or better UTP cable

Star 100M N/A

100Base-T2 802.3y 100Mb/s Two pairs of 100- ohm Category 3 or better UTP cable

Star 100M 100M

Ethernet 1000 Mbps standards

Standard

IEEE

Data

rate

Medium

Topology

Max. cable length


1000Base-LX

802.3z 1Gb/s Long wavelength laser ( 1300nm) over 62.5um multi-mode fiber

Star 316M 550M

1000Base-LX

802.3z 1Gb/s Long wavelength laser (1300nm) over 50um multi- mode fiber

Star 316M 550M

1000Base-LX

802.3z 1Gb/s Long wavelength laser (1300nm) over 10 um Single mode fiber

Star 316M 5000M

1000Base-SX

802.3z 1Gb/s Short wavelength laser (850nm) over 6 2.5um multi mode fiber

Star 275M 275M

1000Base-SX

802.3z 1Gb/s Short wavelength laser (850nm) over 50um multi mode fiber

Star 316M 550M

1000Base- CX

802.3z 1Gb/s Specialty shielded balance d copper jumper cable assemblies

Star 25M 25M

1000Base- T 802.3ab 1Gb/s Four pairs of 100-ohm Category 5 or better cable

Star 100M 100M

of 77

4.2.2.3.2 Other “New Wire Standards” In some case the use of an embedded USB connection can be cost effective (new processor with USB1.1 interface and RTOS with USB stack are available).

The USB 1.1 delivers two data transfer protocols: the Isochronous connection for fast devices (video, audio, and so on) that allows a guaranteed fixed rate of 12 Mbps, and the asynchronous connection that allows an 1.5 Mbps data transfer.

Main strengths of USB are: it is a plug-and-play standard, supports up to 127 local peripherals (using an external USB hub), the USB connection is supported by any modern PC operating system.

Main weaknesses are: short cable (max 5 meters), additional cost if the embedded processor doesn’t include an USB interface, additional effort of FW to support all USB functionalities.

Currently, a new standard named USB 2.0 is in the development phase. This new standard will support up to 480 Mbps (!), but now is too far from the embedded market targets.

4.2.2.4 Local network using existing wires. Two approaches are possible to design local network without new wires: the use of existing phone line or the use of the power line.

Phone line based networks have a substantial limitation for the embedded market: in a production plant the number of telephone line is very low; for what concerns the home networking market only U.S. households have multiple phone jacks, while in Europe we have maximum two jack per house.

For the powerline network many standards are available. The major problem with the power line connection is the line noise and the physical incompatibility of different standard on the same line. To overcome these issues, an organisation called HomePlug powerline Alliance was established in 2000. This organisation has 13 founding members and its mission is to define a complete open specification.

The most famous standard based on existing phone line is HomePNA. Major power line network technologies are CEBus, LONWorks and X-10.

4.2.2.4.1 HomePNA HomePNA is a de-facto industry standard, created in 1998 by a group of 130 companies, using existing phone-lines to transmit data up to 1 Mbps (version 1.0) or up to 10 Mbps (Version 2.0). The standard 2.0 is backward compatible with the 1.0, and forward compatible with future appliance up to 100 Mbps.

This standard is a modification of the Ethernet standard. Use the same IEEE802.3 Media Acees Control (MAC) and Carrier Sense Multiple Access/ collision Detect (CSMA/CD). A chipset for HomePNA2 from Broadcom Corporation is now available.

4.2.2.4.2 X-10 X10 is a power-line solution developed in US, to transmit data with a very low bit rate (60Hz). Main issues of this solution are the low-speed and the full proprietary licence policy (the company does not license others to use it). The only “official” media supported is the power line.

of 77

4.2.2.4.3 CEBus CEBus is a standard that use a peer-to-peer protocol and support speeds up to 10 Kbps. This standard define also a Common Application Language (CAL) that include a set of basic commands, normally used in Home Networking application (temperature UP or Down, Volume Up, and so on).

CEBus use a Carrier Sense Multiple Access protocol with Collision Detect and Collision Resolution (CSMA/CDCR) and deliver a control channel and multiple data channels.

Media supported are Power Lines, twisted pair, coaxial cable, RF, IR and Optical Fiber.

Due to its structure this standard is suitable for home networking but nobody prevents someone from using it in other appliances (it’s a public domain standard and does not require licenses).

4.2.2.4.4 LONWorks LONWorks is a technology developed by Echelon Corporation. This technology supports data rate from 610 bps to 1.25 Mbps, is well specified (including components from physical interface to SW modules), can be integrated in an internet network and supports (also in its power-line implementation) remote monitoring through standard Web browsers. Its architecture does not require central control or master-slave. Each node implements controls and protocol. Media supported are power lines, twisted pair, RF. LONWorks is suitable for a wide range of application (from Home to industrial networking). The following table (source: Xilinx) compares three different powerline technologies:

of 77

Technology X-10 CEBus (EIA IS-60) LONWorks Developer X-10 (USA-Cortp.) Electronics Industry

Association (EIA). Further Developed by CEBus Industry Council (CIC)

Echelon Corp. Testing and certification programs led by LONMark

Association Media Supported

Powerlines. X-10 Manufactures devices for

non standards for them

Powerlines Twisted Pair Coaxial Cable RF IR Eventually Fiber Optic

Power line Twisted Pair RF Third party transceiver support

Max. Data Rate

60 bps 10 kbps, Additional support for video, audio, and data

610 bps to 1.25 Mbps

Licensing nts

Proprietary, company does Not license others to use it

Public domain, does note require a License. Certification Required to Use the CEBus logo

License required. Certification required to Use the LONMark logo

Relative Cost Low Low to moderate Low to moderate Target Application

Existing and new homes Existing and new homes Existing and new homes, Commercial and industrial Buildings, industrial Automation, automotive

Interoperability

Other media, but there are

Requireme

4.2.2.5 Wireless local network. Even if currently it is not a low cost solution, the wireless interconnection is the most flexible for a network: it does not require new wires, it is possible to move a node from a position to another “without limitation (…..)”, is possible to access the physical link from anywhere, anytime (with limitations due to distance and walls). Main issues of these technologies are costs and security of the physical media (is impossible to prevent access to your media link).

Following sections describe most famous radio frequency wireless technologies.

4.2.2.5.1 Wireless LANs (WLAN) A further section at the end of this chapter discusses WLAN solutions.

4.2.2.5.2 HomeRF During 1997 a group of 83+ companies has developed a specification for wireless communication in home. The access protocol, called SWAP/CA (Shared Wireless Access Protocol / Cordless Access), has been developed for home and small office network, and use the 2.4 Ghz band (ISM band – Industrial, Scientific and Medical) that is worldwide available (unlicensed to specific application).

In an HomeRF network there are four type of components: a connection point (CP), a bridge between networked nodes and a PC, Isochronous nodes (I-nodes) for voice appliances, Asynchronous nodes (A-nodes) for data appliances and mixed Asynchronous-Isochronous nodes (AI-nodes).The maximum number of local nodes is 127.

of 77

Current maximum bit rate is 1Mbps, but a modification up to 10Mbps in the 2.4GHz band is under development.

In addition other two specifications are under development: the SWAP-MM for multimedia applications (wireless true video applications) and the SWAP-lite for low-cost, low power nodes. The last one is the most interesting for embedded applications.

4.2.2.5.3 Bluetooth It is a technology developed by telecommunication and computer industries for interconnection between consumer device (mobile telephones, PDA, PC, …). The Bluetooth Special Interest Group include Ericsson, Intel, Lucent, IBM, Motorola, Toshiba, Nokia, Microsoft, 3Com and 2000 adopter companies.

Due to its consumer target Bluetooth is based on a low cost radio link, implemented in a small chipset. The radio link uses the 2.4 GHz ISM band and a frequency hopping scheme with short packets. For security it provides an authentication algorithm at the lower layers of its stack. Maximum data rate is 1 Mbps, with a protocol overhead close to 25%.

Bluetooth supports pointtopoint and pointtomultipoint connections between devices in the same “piconet”. Piconet is a collection of devices (max. 8) in a range of ten meters (the maximum distance supported) using the same hopping sequence. Several piconets can be linked together in a structure named Scatternet. Following table (source Xilinx) summarizes main topics of different wireless Technologies:

FHSS: Frequency Hopping Spread DSSS: Direct Sequence Spread Spectrum OFDM: Orthogonal Frequency Division Multiplexing GMSK: Gaussian Minimum Shift Keying CSM/CA: Carrier sense Multiple Access/Collision Avoidance TDMA: Time Division Multiple Access

Technology Physical Layer Media Access

Control Method Raw Physical-Layer Throughput (Mbps)

IEEE 802.11 FHSS DSSS CSMA/CA 1 or 2 IEEE 802.11b DSSS CSMA/CA 11 IEEE 802.11a OFMD CSMA/CA 54 HiperLAN1 GMSK three-phase priority

driven 23.5

HiperLAN2 OFDM Central resource control, TDMA

54

Open-Air FHSS CSMA/CA 1.6 Wideband Open-Air

FHSS CSMA/CA 10

Home RF FHSS CSMA/CA 1 Wideband FHSS CSMA/CA 10

Bluetooth FHSS Central resource control, TDMA

1 Home RF

of 77

4.2.2.6 CSMA/CA and CSMA/CD. Ethernet MAC (Media Access Control) uses the CSMA/CD media sharing method. It means that an agent looks to the media and if the media is not free (carrier sense), waits until the physical channel is unused. When the channel is available it starts immediately the transmission. If more than one agent starts the transmission at the same time there is a conflict. The agent detects the conflict and stops the transmission, waiting a random time interval. This method, named Carrie Sense with Conflict Detect, works well in a wired system where the error rate due to other factors is very low. Main issue of this method is that if many agents are trying to transmit at the same time the sustained bit rate decreases in a non-linear way.

This method does not work in a radio link for two main reasons: first of all a radio link has an high error rate due to the physical channel, and an approach that does not avoids conflict reduces dramatically the sustained bit rate. The second reason is that is difficult for an agent to detect a conflict because it receives perfectly its own signal while it cannot receive at all the signal of an agent located far away.

For these reasons the 802.11 wireless technology uses the CSMA/CA method (CA means Conflict Avoid). This method uses RTS (Request to send), CTS (Clear to Send) and ACK (Acknowledge). A node starts its transmission with a short RTS, that include the destination and the length of the message. All other nodes in the media back off for the duration of the transmission (a NAV, network allocation vector, is used to implement this service). The addressed node sends a CTS back to the sender (and to the NAV). If the sender does not receive a CTS assumes that a conflict occurred and the process starts over again. When the frame is received the target sends an ACK.

Main issue of this method is known as “the hidden node problem”. The following scheme shows a typical situation where the hidden node problem can occur.

4.2.3 Wireless Local Area Networks (WLAN)

Wireless LAN is a growing market, and is a topic that in itself is deserving of a dedicated manual. This section therefore provides only an overview of the technology. Further information can be found in the text referenced in the bibliography.

WLAN solutions are suitable in applications where is difficult or expensive to implement new wired solutions. Even if this is the main reason of the WLAN success other related improvements are its flexibility and its large range (up to hundreds of meters).

The most popular WLAN technologies are IEEE 802.11(a and b) and HiperLan (1 and 2) families. The following table (source Xilinx) compares the main WLAN technologies

of 77

Characteristic IEEE 802.11b IEEE 802.11a HiperLAN2

Spectrum 2.4GH.z 5GHz 5GHz Maximum physical rate (approx.)

11Mbps 40Mbps 54Mbps

Maximum data rate, layer 3 (approx.)

5Mbps 28Mbps 32Mbps

Medium access control/Media sharing

CSMA/CA Central resource control /TDMA/TDD

Connectivity Connection-less Connection-less Connection oriented Multicast Yes Yes Yes QoS support PCF PCF ATM/802.1p/RSVP/Dif

fServ(full control) Frequency selection DSSS Single carrier Single carrier with

Dynamic Frequency selection

Authentication No No NAI/IEEE address/X.509

Encryption 40-bitRC4 40-bitRC4 DES, Triple-DES Handover support No No No Fixed network support

Ethernet Ethernet Ethernet, IP, ATM,

Management 802.11 MIB 802.11 MIB HiperLAN2 MIB Radio link quality control

No No Link adaptation

UMTS, FireWire, PPP

The fastest growing technology is HiperLAN2. The strengths of this technology are maximum data rate (up to 54Mbps) and wide network support (Ethernet, IP, ATM, UMTS, FireWire, PPP). WLAN adapters cost now from 99 to 200 USD, but the price is expected to decrease during the next few years.

of 77

4.2.3.1.1 The IEEE 802.11 standard Between the IEEE 802.6 and 802.11 committees are a number of committees which are primarily technical advisory groups on broadband, fibre optics and security issues that are not LAN standards.

The IEEE 802.11 group is a relatively new group that addressed the wireless (WLANs), cordless or cableless LANs (CLANs), and has looked at the various alternatives. These options include infrared line of sight transmission, power line transmission, spread spectrum transmission, and microwave transmission. The IEEE 802.11 standards have defined the media access and physical layers for wireless LANs as shown in the following figure.

Infrared light

Direct Sequence

Frequency Hopping

Media Access Control (MAC)

Data link Layer

Logical Link Control (LLC)

Physical Layer

Architectural model of IEEE 802.11 Since the three access techniques shown in Fig. 9.42 tend to be higher priced products than the traditional wired LAN components, then they were initially targeted at niche areas such as: a) Situations where stations frequently move; b) Situations where cabling may be problematic (e.g. point-of-sale terminals); c) Terminals in listed buildings or buildings with marble surfaces (e.g. in financial institutions); d) Areas of hazardous installation for cabling (e.g. asbestos lined areas).

The introduction of the IEEE 802.11 standard and the range of devices typically found in wireless networks has led to the evolution of two styles of configurations. Peer-to-peer networks have evolved in which each wireless station is able to ‘talk’ to any other device in the vicinity. It is not unusual for one of these devices to be a server, providing a service to any other devices that are able to communicate. It is also possible in such an ad hoc network, for the stations to simply be devices that have found themselves in proximity with each other, e.g. laptops in a conference room.

of 77

Peer-to peer configuration Of course in many cases the network applications will require access to wider resources than those normally associated with such simple configurations. In these more formal structures, one or more wireless stations communicate with a base station known as an access point. This arrangement provides the normal building block of a wireless network, each area providing a cell as part of the basic service set. A wireless network may then comprise a number of overlapping cells to provide coverage across a designated area as indicated below.

Access point

wired network

router

Internet

Basic Service Set in a Wireless Network The wireless approach has partly grown from cellular radio technology, and a big thrust is based on spread spectrum transmission (SST) technology. The bandwidth of the transmitted signal is ‘spread’ by modulating it with a random code sequence. Instead of signalling with all the power in a narrow frequency band, the signal power is spread over a wider frequency bandwidth. Hence much lower signal strengths or densities are used than in conventional radio signalling.

This SST signal is restricted in terms of the distance it can travel and it cannot penetrate major obstacles. At the destination, the signal is captured and interpreted to recover the transmitted data. SST contributes to the security of wireless networks, but clearly on its own is not sufficient. It is normal that additional privacy measures such as encryption of data are also implemented, which is adequate for most purposes. The wired equivalent

of 77

privacy (WEP) option in the IEEE 802.11 standard provides the mechanism to implement either a 40- or 128-bit RC4 encryption key. The secret key is used to encrypt packets before they are transmitted, and an integrity check is used to ensure that packets are not modified in transit. In practice, most installations that implement encryption use a single key that is shared between all stations.

Encryption Decryption Cipher-text

Plain text Plain text

Key Key

WEP algorithm produ

To avoid encrypting two cipher-texts with th(IV) is used to augment the shared secret keypacket. The IV is also included as part ofsecurity continue to identify the ease with whinterpreted. The IEEE 802.11 implements CSMA/CA asdefined two forms of spread spectrum operafrequency hopping spread spectrum (802.11 FIn 1999 the standard was updated and the Ddata rates of 11 Mbit/s, but new developmenhancement within the existing standard. operates in the 2.4 GHz ISM band.

An IEEE 802.11a standard was also defined providing speeds of up to 54 Mbit/s. Fuexploring the use of higher frequency bands,the power limits imposed for health and sahand held devices), the operational range at 6

The range for current 2.4 GHz implementatapproaches are:

a) 3COM’s Airconnect which implements

b) Cisco’s Aironet which also implements

Generally, if a high carrier frequency is alloccan typically be supported. The result is a rbehave like a token ring or Ethernet, without th

of

Wireless medium

cing cipher-text

e same key stream, an Initialisation Vector and produce a different RC4 key for each the packet. However recent concerns in ich signals can be received and potentially

the media access technique. The standard ting at data rates of 1 or 2 Mbit/s, namely HSS) and direct sequence (802.11 DSSS). SSS was redefined as 802.11b, providing

ents are actively considering a 22 Mbit/s The IEEE 802.11 and 802.11b standards

in 1999, operating in the 5 GHz range, and ture developments up to 100 Mbit/s are looking at the feasibility of 60 GHz. With fety reasons (and battery conservation for 0 GHz would be about 10 m.

ions is typically 50 m to 100 m. Example

DSS to achieve speeds of 11 Mbit/s;

DSS at 11 Mbit/s.

ated, then a higher bandwidth network ange of wireless networks, which can e inconvenience of cabling.

77

4.2.3.1.2 Frequency Hopping With the ISM band available, it was divided into 79 individual radio frequency channels spaced at 1 MHz apart. Frequency hopping transmits in one channel for a maximum period of time or dwell time, typically 400us. It then hops to another channel in a pseudo-random manner, using a technique known as the spreading code, to send the next part of the transmission. Both the transmitter and the receiver use the same code to lock into the channel hop sequence. Implementing 1600 hops/s on average, there is a small gap between the transmission on each channel to allow the hop to take place, as illustrated below.

frequency

78

0

1

2

3

4

5

2.480

2.402

2.403

2.404

2.405

2.406

2.407

GHz

Transmission slot 625 microseconds

Typical Frequency Hopping Transmission Sequence

The transmission during each of these slots is based on a specific modulation type depending on which data rate is being implemented. GFSK (Gaussian frequecy shift keying) is typical of the modulation approach used, where the frequency of the channel in use is modulated by a fixed amount in either direction from the central frequency of the channel. This frequency modulation is used to represent a 0 or a 1 bit.

5. Direct Sequence Spread Spectrum This approach takes each individual data bit to be transmitted, and represents the 0 or 1 value as a multiple bit sequence. The number of bits used to represent the 0 or 1 value is dictated by the chipping code used. Hence if a chipping code of 11 is set, then one of two different 11 bit sequences will represent each of the two possible data bits. A sequence of 11 bits, based on the standard known as the Barker sequence is normally implemented. The code uses a wider frequency band to achieve transmission. In the IEEE 802.11b standard the DSSS may have up to 13 transmission channels available, each channel with a 5 MHz bandwidth.

The IEEE 802.11 encoding scheme used for signalling the transmission is DBPSK (Differential binary phase shift keying) for 1 Mbit/s rates and DQPSK (Differential quadrature phase shift keying) for the 2 Mbit/s rate.

of 77

To achieve data rates of 11 Mbit/s defined in the IEEE 802.11b standard, a more complex modulation scheme known as CCK (Complementary code keying) is employed. 5.1.1.1.1 MAC layer The MAC layer in the IEEE 802.11 standard is defined as providing station services (which include authentication, de-authentication, privacy and packet delivery) and distribution system services (which include association, disassociation etc).

Authentication is needed to provide control of who is able to gain access to the network and involves exchanging management frames or use of shared key WEP algorithm.

Association is the process of a station linking into an access station. It can only be associated with one access point. If a station roams into another cell area, it needs to re-associate with another access point. To deliver these services a MAC frame structure is used. A number of address fields may be necessary for those occasions when a transmission between two stations is via an intermediate station such as the access point. The frame format is illustrated in the following figure for information.

FrameControl

(2 bytes)

Address 1

(6 bytes)

Duration/ID

(2 bytes)

Address 2

(6 bytes)

Address 3

(6 bytes)

SequenceControl

(2 bytes)

Address 4

(6 bytes)

Payload from LLC(0-2312 bytes)

FCS(4 bytes)

FrameControl

(2 bytes)

Address 1

(6 bytes)

Duration/ID

(2 bytes)

Address 2

(6 bytes)

Address 3

(6 bytes)

SequenceControl

(2 bytes)

Address 4

(6 bytes)

Payload from LLC(0-2312 bytes)

FCS(4 bytes)

IEEE 802.11 MAC frame format

of 77

6. Frequently Asked Questions (FAQ)

Abstract: A few of the more commonly Frequently Asked Questions regarding embedded Internet system developments are included in this section. Further information can be found on the JENET web site, www.eurojenet.com, where a FAQ section and detailed information in the User Experiment reports can be used to gain additional practical insights into using this technology. For a comprehensive range of frequently asked questions about TCP/IP protocols in general the following web site is recommended: http://www.itprc.com/tcpipfaq/default.htm The following FAQ apply specifically to some of the embedded Internet issues that arose during the JENET project. Reference to the final reports for the individual projects at www.eurojenet.com is recommended for further information.

1. What about Security of Embedded Internet systems?

The security of a device connected to the Internet ma should be considered, even if this is only to placate potential customers’ concerns about violation of the system following some high profile hacking case. The various options for implementing security should be viewed in the context of the value of the data to be protected. The security options for a remote camera system would be different in scale to that employed on a cash vending machine. One simple security option is to apply encryption devices to provide a low level of data protection. However, this does not prevent unauthorized access it can provide a low cost solution based on the use of available encryption devices. This level of security is therefore possible in systems using lower end microcontroller devices.

More advanced security can be provided by using IPSec (Secure Internet Protocol) or SSL (Secure Sockets Layer) protocols. However, before considering this level of security it is worth noting that both IPSec and SSL, which manage keys and sessions, require a relatively large amount of code memory, which makes probably unsuitable for 8 bit processors, and possibly for 16-bit processors. If a high level of security is required then this may need the use of a 32-bit processor even if the data throughput is relatively low.

of 77

http://www.eurojenet.com/

http://www.itprc.com/tcpipfaq/default.htm

http://www.eurojenet.com/

IPSec provides network layer encryption, authentication and protection at the network layer based on standards set forth by the Internet Engineering Task Force (IETF). SSL provides encryption, authentication and data integrity for secure application layer communications between web servers and web browsers. SSL is a layered protocol. At each layer, messages may include fields for length, description, and content. SSL takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then delivered to higher level clients. The SSL Protocol provides privacy and reliability between two communicating applications. The protocol is composed of two layers. At the lowest level, layered on top of the transport protocol (e.g., TCP/IP), is the SSL Record Protocol. The SSL Record Protocol is used for encapsulation of various higher-level protocols. One such encapsulated protocol, the SSL Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. One advantage of SSL is that it is application protocol independent. A higher-level protocol can layer on top of the SSL Protocol transparently. The SSL protocol provides connection security that has three basic properties:

• The connection is private. Encryption is used after an initial handshake to define a secret key.

• The peer's identity can be authenticated using asymmetric, or public key, cryptography.

• The connection is reliable. Message transport includes a message integrity check.

The use of certificates also supports the security of the system. Certificates are digital identification documents that allow both servers and clients to authenticate each other. They are required for the server and client's browser to set up an SSL connection over which encrypted information can be sent. Server certificates provide a way for users to confirm your Web site's identity. A server certificate contains detailed identification information, such as the name of the organisation affiliated with the server content, the name of the organisation that issued the certificate, and a public key used in establishing an encrypted connection. This information helps to assure users of the authenticity of Web server content and the integrity of the secure HTTP connection. With SSL, your Web server also has the option of authenticating users by checking the contents of their client certificates. A typical client certificate contains detailed identification information about a user and the organization that issued the certificate and a public key. You can use client certificate authentication, along with SSL encryption, to implement a highly secure method for verifying the identity of your users. Depending on the embedded resources available, designers can therefore select between a number of security measures to prevent attacks.

of 77

The first measure is to isolate the embedded local network from outside. If it is possible to locate the embedded network and server in the same place without Internet access the security problem seems to be resolved. This is true if you are using a network with dedicated wires (e.g. Ethernet), but what happens if you use a wireless or a power line connection? In this case you have to use a network technology that implement an encryption-authentication layer. This comes at increased cost and decreased performances. This means: “try to use a wired solution; it is less expensive and more secure”. In many appliances it is impossible to separate the embedded system from the Internet (e.g. remote machines control). In this case it is better to partition the local network with a gateway. With this approach it is possible to increase the cost of the gateway, implementing all security layers between the gateway and Internet, minimising the cost of local nodes. If it is impossible to separate the node from the Internet (e.g. an isolated vending machine with a local modem), it is better to use an embedded operating system with security facilities or use a third party Internet chip with security services. This reduces design costs and increases system security. In any case a short connection at random times, protects your system from many hacker attacks. This simple overview indicates that the adoption of higher-level security systems for embedded Internet equipment is costly in terms of program development and processor hardware requirements. Before embarking on such a secure system development the cost of unauthorised access should be evaluated. 2. What issues should I consider when selecting a ISP? An ISP (Internet Service Provider) must be selected who offers a conventional log on procedure and SMPT and FTP facilities. These means that many large ISP's won't work in an embedded system because these offer a non standard logon sequence. Upon connection the ISP will negotiate a link using LCP (Link Control Protocol), and both sides will try to decide on a set of stack facilities to use for the connection. If the LCP phase is successful then IP addresses are allocated by the ISP. At this point the system is connected to the Internet via the ISP. In order to send email via SMTP the system must first open a connection with a mail server. In some instances the static address of the email server must be known. On a normal PC type system a DNS (domain name server) lookup is performed on a secondary server to derive the IP address. The mail server must be owned by the ISP that we have dialled in upon or else the mail server will not allow messages to be sent to other domains. Generally a mail server not belonging to the ISP will only allow emails to be sent to domains on the same server. The basic reason for this routing restriction is because for SMTP the email server doesn't know who you are by default, and therefore prevent unauthorised forwarding of mail messages. If however you log on to your ISP using an account and send email using their server, then they have knowledge about who you are. Some mail servers will allow you to route email from a foreign ISP if you log onto a POP3

of 77

account first. This allows the email server to identify you, and so allow access to these facilities. This is not possible if there is not a POP3 email receiving facility. 3. What happens in the event of the embedded Internet unit not connecting correctly? Phone connectivity is one of the most common methods of connecting devices. Most environments have a phone line available and the device can "borrow" the line without interfering with normal use. This model represents a passive server model. A management server collects information passively when the device calls in. Without a dedicated number or a special ring, a server could not call the device without interfering with normal use of the phone. The problem with a passive model, however, is that if the device doesn't call in or, if in the worst case, the phone is off the hook or the modem is damaged, then the server has no way of knowing whether the device is down. The server cannot establish if then there is a problem or if there is nothing to report. Periodic calls are required from the embedded device even if there is nothing to report to establish the correct operation at the remote end; if no connection is made within a timeout period then a service operation is initiated. This action could be a telephone instruction to the customer site to ask a service engineer to press a reset button, or a physical call out by the company’s service staff. If more rapid detection of remote failures is required, this should be implemented in the application protocol. There is no standard mechanism for this, but an example is requiring clients to send a "no-op" message every minute or two. An example protocol that uses this is X Display Manager Control Protocol (XDMCP), part of the X Window System, Version 11. The XDM server managing a session periodically sends a Sync command to the display server. This then evokes an application-level response, and resets the session if it doesn't get a response (this is actually an example of a poor implementation, as a timeout can occur if another client "grabs" the server for too long). 4 How do I know the ISP address of my embedded system? If the embedded device is connected to the Internet through an ISP connection there is a potential problem as the embedded device will not have a static IP address allocated to it. How can a user see the remote web page? A possible solution is the implementation of a web-on-demand service that uses dynamic IP for the remote unit. An ISP provider that supports the web-on demand service (called in the text WOD-ISP), resolves the address of that device. When a user wants to access the embedded device, the WOD-ISP calls the remote modem. The remote controller detects the ring and, if possible, identifies the caller. After the ring detection, the remote device calls its local ISP and establishes an Internet connection. When the connection is established the remote embedded device sends its actual IP address to the WOD-ISP that uses it to resolve the address to all users actually connected.

of 77

Another example is the following: a company uses the embedded Internet to collect data from remote vending machines. Normally the remote machine sends an e-mail per day with a report on cash flow and machine status. If there is an alarm (e.g. the coffee is finished), the machine sends an e-mail to the control center (and for example to the GSM of the maintenance personnel). If the control center wants to change the price of goods, it sends an e-mail to the remote machine. When the machine checks the e-mail (one time per day), updates its local prices. If the control center wants to send a message to the machine in quasi-real time, it can send the e-mail and call the remote modem. When the remote local controller detects the ring (and identifies if possible the caller), it then establishes a connection with its local ISP and checks the mail. In this way it is possible to implement a bi-directional data exchange using only a “low-cost” e-mail protocol. This method can be used also for the firmware update of the remote unit. The design center sends an e-mail to the target with attached the new firmware. The remote unit receives the mail and stores the attachment in a local non-volatile memory (e.g. a flash). After the receiving of the e-mail the remote unit starts a local update procedure. When the procedure is completed it sends an e-mail to the design center to confirm the update. This approach requires a local non-volatile memory overhead but is more conservative than a true on-line FW update. 5 What are sockets? Sockets are just like "worm holes" in science fiction. When things go into one end, they (should) come out of the other. A socket is therefore an abstraction that represents an endpoint of communication. Different kinds of sockets have different properties. Sockets are either connection- oriented or connectionless. Connection-oriented sockets allow for data to flow back and forth as needed, while connectionless sockets (also known as datagram sockets) allow only one message at a time to be transmitted, without an open connection. Most applications that consciously use TCP and UDP do so by creating a socket of the appropriate type and then performing a series of operations on that socket. The operations that can be performed on a socket include: • control operations (such as associating a port number with the socket, initiating or

accepting a connection on the socket, or destroying the socket) • Data transfer operations (such as writing data through the socket to some other

application), or • Reading data from some other application through the socket), and status

operations (such as finding the IP address associated with the socket). The two most common socket families are AF_INET for internet connections, and AF_UNIX for unix IPC (interprocess communication). The complete set of operations that can be performed on a socket constitutes the Sockets API (Application Programming Interface). If you are interested in writing programs that use TCP/IP then you'll probably need to use and understand the sockets API. A FAQ list for sockets programming is available on the Web from <http://www.ibrado.com/sock-faq/>, from a UK mirror at

of 77

http://www.ibrado.com/sock-faq

<http://kipper.york.ac.uk/%7Evic/sock-faq/> or by anonymous FTP from <ftp://rtfm.mit.edu/pub/usenet/news.answers/unix-faq/socket>. 6 If I use a TCP/IP interface device can I use an 8bit microcontroller in the

system? In principle the use of a TCP/IP interface device with a serial input and outputs for either a modem or an Ethernet physical layer interface device will enable the use of a low end microcontroller, such as those in the PIC. AVR, and similar series of devices. However, careful consideration of the set up of the device should be considered in terms of the limited memory sizes in these devices. For example, if several strings of commands has to be transmitted to the device this could use a significant memory space, or if for example contiguous data must be passed to the device to enable for example an FTP operation then the demand on internal RAM may be significant. However, as demonstrated in the JEENT projects (refer to www.eurojenet.com) the transmission of emails and low volumes of status data has been achieved using these devices. These facilities should be more than adequate for most embedded Internet requirements. 7. For further information The Internet provides many briefing documents on TCP/IP protocols. Search on the RFC comments regarding for proposed amendments to the protocols and is worth a review if detailed knowledge of a particular aspect of TCP/IP is required. A selection of article sources is provided in the bibliography.

of 77

http://kipper.york.ac.uk/~vic/sock-faq

ftp://rtfm.mit.edu/pub/usenet/news.answers/unix-faq/socket

http://www.euro-jenet.com/

7. Glossary of Terms

ADSL

Asymmetric Digital Subscriber Line. A technology for transmitting digital information at high bandwidths on existing phone lines to homes and businesses. ADSL is asymmetric in that it uses most of the channel to transmit downstream to the user and only a small part to receive information from the user. ADSL simultaneously accommodates voice information on the same line. ARP Address Resolution Protocol. ARP associates an IP address to a hardware address called a Media Access Control (MAC) address. BOOTP Bootstrap Protocol. The Bootstrap Protocol is a variant of DHCP, which must be enabled at the client.

Bridge

A bridge connects two LANs (local-area networks) or two segments of the same LAN. Unlike routers, bridges are protocol-independent and simply forward packets without analyzing and re-routing messages.

DHCP

Dynamic Host Configuration Protocol. A communications protocol for organising and simplifying the administration of IP configuration for computers in a network. Without DHCP, the IP address must be entered manually at each computer and, if computers move to another location in another part of the network, a new IP address must be entered.

DNS

Domain Name System. DNS is a naming scheme for IP addressing. Easy to remember domain names are matched to a string of numbers, the IP address, by a DNS server.

DSL

Digital Subscriber Line. A technology for bringing high-bandwidth information, data and voice, to homes and small businesses over ordinary telephone lines.

Embedded Internet

A microprocessor system that includes embedded software and hardware to connect to the internet.

Ethernet

Most widely used LAN technology, which uses coaxial, twisted-pair and fibre optics cable as communication medium. The Ethernet specification served as the basis for the IEEE 802.3 standard, which specifies the physical and lower software layers for the TCP/IP protocol suite.

of 77

ETRN

The ETRN command is used when an SMTP server is not online 24 hours a day. An ETRN enabled SMTP server will hold messages in the queue until another SMTP server uses the command to have them flushed.

Firewall

A filtering module/program located on a gateway computer that examines all incoming and outgoing traffic to determine if it may be routed to its destination. Rules can be assigned for specific IP addresses and ports.

FTP

File Transfer Protocol. FTP is an application protocol that allows to transfer, delete, move, rename or copy data between two machines across the internet.

Gateway

The point of entrance to a network from another network. A gateway distributes data coming in and going out of a local area network.

Handshaking

Control information transmitted between the sending and receiving devices to establish and coordinate the data flow between them.

Header

A header precedes the data or control signals and describes something about the file or transmission unit, such as its length and whether there are other files or transmission units logically or physically associated with this one.

Host

On the Internet, the term "host" means any computer that has full two-way access to other computers on the Internet. In other contexts, the term generally means a device or program that provides services to some smaller or less capable device or program.

Host table

A list of TCP/IP hosts on the network along with their IP addresses.

HTTP

Hypertext Transfer Protocol. A set of rules for exchanging files (text, graphic images, sound, video, and other multimedia files) on the World Wide Web. Relative to the TCP/IP suite of protocols, HTTP is an application protocol.

ICMP

Internet Control Message Protocol. ICMP uses datagrams to report information between routers.

of 77

Internet

A worldwide system of computer networks - a network of networks in which users at any one computer can, if they have permission, get information from any other computer.

Intranet

Private network that is contained within an enterprise. It may consist of many interlinked local area networks and also use leased lines in the wide area network. When part of an intranet is made accessible to customers, partners, suppliers, or others outside the company, that part becomes part of an extranet.

IP

Internet Protocol. IP specifies the format of packets and the addressing scheme. Most networks combine IP with a higher-level protocol called Transport Control protocol (TCP), which establishes a virtual connection between a destination and a source.

IP address

The IP address is a unique 32-bit number, which identifies a computer in an IP network.

IPSEC

Internet Protocol Security. IPSEC allows virtual private networking using authentication and encryption between IP networks.

LAN

Local Area Network. LAN is a group of interconnected computers with the ability to share resources. Most LANs are confined to a single building or group of buildings.

Layer/layering

The organization of programming into separate steps that are performed sequentially, defined by specific interfaces for passing the result of each step to the next program or layer until the overall function, such as the sending or receiving of some amount of information, is completed. Communication programs are often layered.

MAC address

Media Access Control address. The MAC address is a 48-bit long, unique address that is specific to each network hardware device. While routers use IP addressing for routing decisions, switches use MAC addressing for path determination.

OSI

Open System Interconnection. OSI is the reference model for communication programs. OSI consists of seven layers, each reflecting a different function that has to be performed in order for program-to-program communication to take place between computers.

of 77

Network interface

A network interface is any device that connects a computer to a communication medium. A network interface may be an Ethernet card, modem, ISDN card, etc.

Network Mask

The Network mask is used to group IP addresses. Group of addresses are assigned to each network segment. For example, the mask 255.255.255.0 groups together 254 IP addresses.

NIC

Network Information Center. The NIC is a facility available to all Internet users which provides information to the community.

Packet

A packet is a basic communication data unit used when transmitting information over the network. The maximum length of a packet depends on the communication medium.

POP3

Post Office Protocol. The POP3 protocol is a TCP protocol using port 110. It is used to receive email.

Port

A port is a 16-bit number used by the TCP and UDP protocols. Ports are used to address different applications (services) that run on a computer.

PPP

Point-to-Point Protocol. PPP is a protocol for communication between two computers using a serial interface, typically a personal computer connected by phone line to a server. PPP uses the Internet protocol (IP) and allows to connect to the internet via the server.

Protocol

Defines rules for the transmission of data.

RAS

Remote Access Service. RAS is the ability to dial into another computer or network remotely.

Remote access

The ability to log onto a network from a distant location. Generally, this implies a computer, a modem, and some remote access software to connect to the network. Remote access means that the remote computer actually becomes a full-fledged host on the network. The only difference between a remote host and workstations connected directly to the network is slower data transfer speeds.

of 77

Repeater

A device that extends the distance of a particular network run. Most often seen on Ethernet networks, they are available for virtually any network connection. Repeaters operate at the physical layer of the OSI networking model.

RFC

Request for Comments. The internal workings of the Internet are defined by a set of documents called RFCs. RFCs are created to formalise an issue and are then commented upon by all those wishing to take part in the discussion (electronically of course).

Router

A Router connects LANs together in order to enable the correct communication between them. Routers use headers and a forwarding table to determine where packets go, and they use ICMP to communicate with each other and configure the best route between any two hosts.

Routing Table

The Routing Table defines which interface should transmit an IP packet in order to reach it destination.

SLIP

Serial Line Internet Protocol. SLIP is a way of running TCP/IP via phone lines to allow dialup to an Internet host.

SMTP

Simple Mail Transfer Protocol. The SMTP protocol is a TCP protocol used in sending and receiving e-mail (port 25).

Socket

An addressable point that consists of an IP address and a TCP or UDP port number that provides applications with access to TCP/IP protocols.

SSL

Secure Socket Layer. SSL is a commonly-used protocol for managing the security of a message transmission on the Internet. SSL uses the public-and-private key encryption system from RSA, which also includes the use of a digital certificate.

Switch

A switch is a network device that selects a path or circuit for sending a unit of data to its next destination. A switch may also include the function of the router.

10Base-T-2, 10Base-T-5, 10Base-F

This designation is an IEEE shorthand identifier. The "10" in the media type designation refers to the transmission speed of 10 Mbps. The "BASE" refers to

of 77

baseband signalling, which means that only Ethernet signals are carried on the medium. The "T" represents twisted-pair; the "F" represents fiber optic cable; and the "2" and "5" refer to the coaxial cable segment length.

TCP/IP

Transmission Control Protocol/Internet Protocol. The suite of communications protocols that is the de facto standard used to connect hosts on the internet.

Telnet

Telnet. Offers access to another computer. Telnet is a user command and an underlying TCP/IP protocol for accessing remote computers and executing applications.

TFTP

Trivial File Transfer Protocol. TFTP is simpler version of the File Transfer Protocol (FTP), which is less capable. It is used where user authentication and directory visibility are not required.

Tunneling

In computer networks, the act of encapsulating one communications protocol within another with the purpose of passing through different networks.

UDP

User Datagram Protocol. Uses a special type of packet called a datagram. Datagrams do not require a response; they are one way.

VPN

Virtual Private Networking. VPNs allow machines to communicate across networks, typically over an encrypted channel.

WAN

Wide Area Network. A geographically dispersed telecommunications network, the term distinguishes a broader telecommunication structure from a local area network (LAN).

of 77

Bibliography Text Books “Embedded Ethernet and Internet Complete - Designing and Programming Small Devices for Networking” (Jan Axelson ISBN 1-931448-00-0)

“TCP/IP Lean – Web Servers for Embedded Systems” (Jeremy Bentham, ISBN: 157820108X).

“TCP/IP Application Layer Protocols for Embedded Systems” (M.T Jones, ISBN: 1584502479)

“Networking and Internetworking With Microcontrollers”, (F Eady, ISBN 0750676981)

“Mobile Telecommunication Protocols for Data Networks” (A Hac, Wiley, ISBN 0470-85056-6)

Web site articles “Embedded Service Provision For Industrial Internet”- http://ethernet.industrial-networking.com/articles/i12internet.asp

“Internet Appliances”, W Wong, ED Online, http://www.elecdesign.com/Articles

“Network-Based Debugging: Internet Appliances In The Wild”, W Wong, ED Online, , http://www.elecdesign.com/Articles

“Boost Internet-Based Applications With Embedded Device Gateways”, M Howard, ED Online, http://www.elecdesign.com/Articles

“TCP/IP For 8- And 16-Bit Devices”, W Wong, ED Online, , http://www.elecdesign.com/Articles

“Programmers ramp for Internet enabled control for embedded devices”, http://www.eetimes.com/story

“The How And Why Behind Internet-Enabled Embedded Systems”, J Dickie, http://www.wsdmag.com/Articles

“IPv6 on a microcontroller”, Robert Muchsel, http://www.embedded.com/showArticle.jhtml?articleID=10800232

“Wireless-Internet Access Gets Easier And More Confusing”, J Blyer, www.wsdmag.com/Articles

“Internet Appliance Interface”, Myron Loewen, July 1999 www.circuitcellar.com

“Internet Connectivity A Singer”, October 2000, www.circuitcellar.com

“Internet Appliance Technology automates test equipment”, October 2000, www.circuitcellar.com

“Directing Distant Devices”, Warren Webb, Feb 2001, www.ednmag.com

“Web technology”, D.Strassberg, Feb 2001, www.ednmag.com

“Working with a player”. F Eady, June 2001, www.circuitcellar.com

“Embedded TCP/IP: a smorgasbord of options”, N Cravotta, January 2001 www.ednmag.com

of 77

http://ethernet.industrial-networking.com/articles/i12internet.asp

http://ethernet.industrial-networking.com/articles/i12internet.asp

http://www.elecdesign.com/Articles




http://www.eetimes.com/story

http://www.wsdmag.com/Articles

http://www.circuitcellar.com/



http://www.ednmag.com/




of 77

“Managing Internet-enabled devices”, N. Cravotta, September 2001, www.ednmag.com

“Reaching Out: off the shelf embedded network connectivity”, N Cravotta, November 2002 www.ednmag.com



c&g water management system

Documents