Airport projects

09/06/2009 by David Slade.

 Below are the current UK Airport projects underway.

The numbers

£9 billion – potential cost of 3^rd runway at Heathrow and new terminal

£35 million – Manchester Airport investment in terminal upgrade

2017 – year that Crossrail will link central London to Heathrow

£1.3 billion – estimated cost for Gatwick Airport

235 million – passengers handled by UK airports in 2008

Airport projects

Project Value/£m Airport Contract Stage

Runway and terminal 3000 Heathrow (BAA) Pre-tender
Runway 1400 Stansted (BAA) Pre-tender
Terminal 126.9 Manston Airport Pre-tender
Northwest zone refurb 40 Gatwick (BAA) Costain
Terminal extension 30 Edinburgh (BAA) Balfour Beatty on site
Runway improvements 25 Carlisle Tenders invited
Framework 25 Newquay Cornwall Tenders leading to three framework contractors
Terminal extension 22.5 Leeds Bradford Mace is construction manager
Framework 20 Bristol International Tenders returned
Terminal works 15.5 Heathrow (BAA ) Balfour Beatty on site
Facilities improvements 13.5 Stansted (BAA) Tenders invited from framework
Terminal extension 11.1 Heathrow T4 (BAA) Taylor Woodrow
Terminal development 7.5 Liverpool John Lennon Tenders invited
Car rental centre 7 Edinburgh (BAA ) Kier on site

Note to self

Need to recall how to add tabs in CSS to align text

Posted in Airport, Aviation, Construction workload | No Comments »

Business confidence Lloyds TSB indicator - May09

09/06/2009 by David Slade.

Business confidence in the UK rose for a third consecutive month in May to its highest level in nearly a year, according to the latest Lloyds TSB Business Barometer.

The survey of more than 200 firms found that 44% expect their business activity to increase during the next 12 months, compared with 35% who stated this in April. Only 16% of respondents expect business activity to decrease, down from 21% who thought this in the previous month.

“While it would be premature to talk of an end to the recession, we should be careful not to overlook the significance of the growing confidence we are witnessing amongst businesses,” said Trevor Williams, chief economist at Lloyds TSB Corporate Markets.

Posted in Construction workload | No Comments »

Homebuyers - May09

09/06/2009 by David Slade.

New homebuyer enquiries increased for the seventh consecutive month and the net balance of house surveyors reporting falling rather than rising prices narrowed in May to 44%, according to data from the Royal Institute of Chartered Surveyors (RICS).

Although the majority of surveyors are still reporting that house prices are declining, the latest reading of 44% represents the best result since November 2007.

Further evidence that the housing market may have started to recover occurred last week when the Bank of England reported a rise in mortgage approvals in May and Hometrack, a provider of housing information, announced an increase in house sales.

Posted in Construction workload | No Comments »

Taking the guesswork out of timing in real-time software systems

09/06/2009 by David Slade.

A new technique, static timing analysis, based on a deterministic processor architecture, is described in this article and will be shown to be capable of taking the guesswork out of timing in real-time software systems.

Guaranteeing correct operation of real-time software running on an embedded processor is a significant challenge. Data dependent execution flows, where execution times of many functions are dependent on the data inputs, mean that instruction sequences are very difficult to accurately time.To handle the problem so far, the test bench has been relied upon to adequately exercise the timing corner cases of each individual function. In complex systems this often means developing much of the rest of the application before suitable stimulus can be created. This adds significant effort and delay to certifying software system timing.

New processor architectures, capable of exhibiting deterministic instruction timing, open up interesting possibilities for the future. A new technique, static timing analysis, based on a deterministic processor architecture, is described in this article and will be shown to be capable of taking the guesswork out of timing in real-time software systems.

In short, a static timing tool will analyse object code and determine worst-case timing paths. Paths are analysed between two points interactively or against timing assertions in batch mode to produce a pass or fail result. This information allows the designer to optimise timing critical sections of their code until correct timing closure is achieved.

The article will show how this approach can be successfully used to develop a software implementation of a 100Mbps Ethernet MII interface.

Closing timing in real-time systems

As processor architectures improve in speed and responsiveness, it becomes increasingly attractive to perform functions traditionally implemented in hardware, using software. A simple example such as an IIC master has always been a good candidate for this approach because the master defines the timing. However, an IIC slave must always be ready to respond within a certain time. This imposes timing constraints on the software. Developing interface functions in software thus becomes a real-time programming challenge.

Verifying software functionality is a well practiced task using software test benches. Closing timing may require a significant amount of additional effort on top of authoring the code. The standard approaches to closing timing are limited. Typical approaches include testing in circuit whilst observing pin activity, simulating the software using a cycle accurate simulator or counting the instructions for the path of interest to determine the expected execution time.

All approaches share a common requirement; that is to provide suitable stimulus to fully exercise the software under test ensuring that corner cases are adequately covered. This increases the verification effort due to extending the test bench to include timing. In many cases, obtaining suitable stimuli may not be possible until much later on in the project when the rest of the system is available to generate it. Static timing analysis removes this dependency by formally exercising all paths within the code and allows timing closure of each software function individually.

he Ethernet MII interface is a good example of where it is advantageous to use interface functions developed in software. Replacing the MAC layer with software allows early adoption of new hardware standards and allows custom protocols to be implemented. The timing diagram of the MII interface between the MAC and PHY layers is shown below in figure 1.

Figure 1: Ethernet MII timing diagram.

The source code to manage the MAC / PHY interface is shown below. It is written in XC which has support for direct control of physical pins through port inputs (:>) and outputs (<:). XC also has support for simultaneously managing multiple ports using the select statement. The select statement is like a switch statement done by the hardware. In this case the pins have been mapped to the port_rxd and port_rx_dv ports and the data port (port_rxd) has been configured to convert the stream of data nibbles coming from the PHY into a series of words. The timing pragmas that instruct the static timing analysis tool are also included in the source code.

Before the receiver starts it ensures that the RX_DV signal is low. Then it looks for the start of packet identified by RX_DV going high and the SFD (Start Frame Delimiter) being received. The inner loop simultaneously waits for data words and the RX_DV going low. When RX_DV goes low the code processes any remaining data nibbles and checks for errors before starting to receive the next packet.

The software managing this interface must not only be functionally correct but also timing-safe as failing to meet timing is equally critical. The timing constraints are in the loop receiving data words (T₁) and the inter-frame gap (T₂ - data valid going low to detecting the next SFD). For 100Mbs Ethernet a word of data is received every 320ns. The inter-frame gap is a minimum of 96 bit times, and the preamble is 56 bit times. Hence the inter-frame code must complete in 1520ns.

The challenge is in guaranteeing the code is timing-safe. There is only one valid path through the function for receiving data, but the inter-frame code has a number of paths to handle different packet sizes and error cases. Each of these must be functionally correct as well as meet timing.

Manually ensuring that all paths meet the constraints is time consuming, especially since it must be repeated every time the code is modified or re-compiled.

The aim of the approach is to automate the task of verifying that software meets timing constraints and to reduce the risk involved with checking timing constraints. Given a deterministic architecture on which to run the software it becomes possible to ensure that worst-case execution time is fast enough to meet the constraints.

The user starts by identifying the path end points in the code which they are timing. The MII source code shows how pragmas have been used to specify these end points. A combination of compiler, simulation and search techniques are used to ensure that all valid paths through a program are evaluated. Only paths explicitly excluded by the user will be ignored, these are known as false paths.

The interactive GUI or console illustrated in figure 2 can be used to visualise the execution paths through the code and identify which are false paths. In the MII code the first timing constraint runs from the word_receive label round the loop back to itself.

Figure 2: Static timing analysis tool GUI image

Two potential paths are found, the tight inner loop and a path which leaves the inner loop and goes through the code waiting for the next SFD. The second timing constraint, the inter-frame gap, runs from the rx_dv_low to wait_for_sfd. The tool finds all possible paths of execution between these two points, including false paths which pass through the word receive loop. With this information the user can create a script to run after every compilation which guarantees that the code meets the timing constraints.

In the case of the MII code the script would look like:

The assertions check the slack or violation for all possible paths of execution which have not been excluded and report the worst-case. For the MII case the output is:

The tool can be used for more than batch pass/fail testing. Code can be analysed using both the GUI and console. Structural code views highlight timing hot-spots. Instruction-level views and traces highlight hardware resource contention. This information is especially useful in allowing the user to concentrate their optimisation efforts where they will have the greatest impact.

In some cases the tool is unable to time code without additional information from the user. Execution flow which is data-dependent, like an unknown loop count, needs the user to specify worst-case values in order to perform timing analysis. These unknowns are highlighted to the user and can be specified through the GUI or console.

The tool works with binary executable files. There are two reasons for this. Firstly, it ensures the accuracy of the timing analysis. Secondly, it makes it language-independent, supporting code generated from any compiled source, be it assembly, C, C++ or XC. The user is able to work at the level of source code wherever debug information is available and can always work at the level of machine instructions.

The case study has shown how a practical real-time software implementation has been proved to be timing-safe through the use of a static timing analysis tool. Whilst this is the main goal of such a tool, the technology opens up further possibilities.

XC includes direct support for timed input/output operations. This means it is possible for the tool to identify these instructions and automatically generate the appropriate timing constraints. For example, the code between two timed inputs can automatically be verified as timing-safe by the tool.

The ability to generate a pass/fail result on timing-safe code enables the toolchain to close the loop. From a suitable report file, the compiler is able to determine where optimisation is needed and apply appropriate heuristics in an iterative manner to help close timing, without any effort from the designer.

The static timing tool identifies all paths through the code, including the worst case. By analysing the data that causes the worst-case timing, it is possible to reverse engineer the stimulus that caused this case. The worst-case test stimulus can then be added to the test bench used at a later stage, such as when testing in hardware. This gives the designer confidence that the test stimulus really does cover the corner cases.

One final interesting possibility is for power optimisation. Power consumption is closely matched to instruction execution, particularly for event driven processors that can enter a low power state when busy waiting. Analysis and optimisation of timing paths between pausing instructions allows the energy consumed per loop iteration to be determined and consequently reduced through optimisation. Saving power is always desirable and has commercial benefits which ripple through the rest of the system.

Designing real-time software capable of performing hardware functions is an attractive prospect however the flow has so far been missing a comprehensive tool to certify timing. With the introduction of static timing analysis, it is now possible to guarantee the execution time of real-time software running on a deterministic processor.

Static timing analysis also brings the advantage that timing closure of individual functions can be achieved well in advance of a full test bench or the rest of the system being available. By using formal analysis of the code, the static timing analyser exhaustively analyses all paths ensuring that no corner cases are missed. Adding timing assertions to the source code using #pragma statement means that the source code not only describes the functionality, but also defines the required timing. This allows the code to not only be portable across suitable architectures, but also timing-safe.

Static timing analysis takes the guesswork out of timing real-time software systems.

Accurate instruction timing predictions are fundamental requirement for a static timing analysis tool. There are many reasons why a sequence of instructions may not always take the same time to execute.

Interrupts by nature alter the execution flow dramatically by forcing a change of the CPU context for an amount of time. Further, all RTOSs have critical sections of code where interrupts are disabled. This means only one task can truly be real-time in a single threaded system and this is likely to be the scheduler in systems utilising an RTOS.

Architectures that include a memory hierarchy and cache memory in particular are known to exhibit less predictable execution times. The previous contents of the cache very strongly influence timing unless cache lines can be locked.

Resource conflict also can also increase execution time. Being denied a hardware resource will naturally block execution and adversely affect timing.

By avoiding these architectural issues, and employing simple round-robin scheduling, event driven, hardware multi-threaded processors provide highly predictable worst case execution timing. Further, the ability to pre-load output ports with a valid time allows execution to continue whilst the port autonomously handles the timed output.

Only data dependent execution flow may impede accurate timing prediction for event driven, hardware multi-threaded processors. A static timing tool is able to determine all possible paths through the software, allowing for the variability due to data dependencies and allowing timing guarantees to be made.

Posted in real-time | No Comments »

Building wireless sensor networks

09/06/2009 by David Slade.

Competitive pressures, globalization, rising energy prices, and increasingly stringent regulations are driving companies to cut costs while increasing efficiency and productivity. Industry leaders feel pressure to adopt new technologies that will help them gain competitive advantages wherever they can find them. One of these promising new technologies is wireless sensor networking. Wireless sensor networks (WSNs) dramatically reduce the cost of installing and commissioning instrumentation in industrial facilities. More instrumentation means better visibility into operational and environmental variables that affect overall uptime, safety, and compliance.

WSNs connect critical processes and assets with the systems or experts that can interpret the data or take immediate action. At the end of the day, operational teams with more visibility into their processes can prevent unplanned shutdowns, increase efficiency, and keep workers safe.

WSN is a term used to describe an emerging class of embedded communication products that provide redundant, fault-tolerant wireless connections between sensors, actuators and controllers or systems. WSNs provide access to assets or instruments that were previously deemed unreachable due to physical or economic barriers.

The WSN label typically describes products that provide performance above and beyond traditional point-to-point solutions, particularly in areas of fault tolerance, power consumption and installation cost.

Wireless Challenges While wireless provides clear cost and flexibility advantages, it also presents some challenges. Point-to-point radio communication links are notoriously variable and unpredictable.

A link that is strong today may be weak tomorrow due to environmental conditions, new obstacles, unanticipated interferers and myriad other factors. These factors can be boiled down into three major failure modes: interference, changes in the physical environment that block communication links, and loss of individual nodes.

RF interference: The small portion of the electromagnetic spectrum devoted to general-purpose wireless communication devices is crowded with traffic from Wi-Fi networks, cordless telephones, bar-code scanners, and innumerable other devices that can interfere with communications. Because there is no way to predict what interferers will be present in a facility at a given location, frequency, and time, a reliable network must be able to continually sidestep these interferers on an ongoing basis.

Blocked Paths: When a network is first deployed, wireless paths are established between devices based on the immediate RF environment and available neighbors. Unlike wired networks, these variables often change; paths may later be blocked by new equipment, repositioned partitions, delivery trucks, or very small changes in device position.

Assuring reliability for the life of the network, not just the first few weeks after installation, requires continually working around these blockages in a transparent, automatic fashion.

Node Loss: Node loss is an important issue to consider with wireless sensor networks. While node failure because of semiconductor or hardware malfunction is rare, nodes may be damaged, destroyed or removed during the life of the network.

Additionally, power surges, blackouts, or brownouts can cause nodes to fail unless they have an independent power source. End-to-end reliability requires the networking intelligence that routes around the loss of any single node.

Any of these problems will bring down a point-to-point wireless link. However, with a network architecture designed to protect against these issues, the network can isolate individual points of failure and eliminate or mitigate their impact, allowing the network as a whole to maintain very high end-to end reliability in spite of local failures.

Similarly, a well-designed wireless network architecture will transparently adapt to changing environments, allowing long-term operation with zero-touch maintenance.

WSNs aim to overcome these challenges by applying self-organizing and self-healing intelligence to continuously adapt to unpredictable conditions. The goal of WSN technology is to provide extremely high reliability and predictability for years at a time without constant tuning by wireless experts.

Time Synchronized Mesh Protocol (TSMP) provides a mechanism for WSN intelligence. By defining how a wireless node utilizes radio spectra, joins a network, establishes redundancy and communicates with neighbors, TSMP forms a solid foundation for WSN applications.

TSMP Overview TSMP is a media access and networking protocol that is designed specifically for low power, low-bandwidth reliable networking. Current TSMP implementations operate in the 2.4 GHz ISM band on IEEE 802.15.4 radios and in the 900 MHz ISM band on proprietary radios.

TSMP is a packet-based protocol where each transmission contains a single packet, and acknowledgements (ACKs) are generated when a packet has been received unaltered and complete. Mechanisms are in place to transport packets across a multi-hop network as efficiently and reliably as possible. All measures of reliability and efficiency are done on a per-packet basis.

Packet Structure TSMP packets consist of a header, a payload and a trailer. Packets contain fields that identify the sending node, define the destination, ensure secure message transfer and provide reliability and quality of service information. For the purposes of this article we will discuss the implementation of TSMP on IEEE 802.15.4 radios.

The IEEE 802.15.4 standard specifies a maximum packet size of 127 B, TSMP reserves 47 B for operation, which leaves 80 B for payload.

Time Synchronized Communication All node-to-node communication in a TSMP network is transacted in a specific time window. Commonly referred to as Time Division Multiple Access (TDMA), synchronized communication is a proven technique that provides reliable and efficient transport of wireless data.

Unlike wired systems where nodes can be directly connected by a dedicated wire (media), to the exclusion of neighbors, in a wireless system all devices within range of each other must share the same media. Several other Media Access Control (MAC) mechanisms are available including CSMA, CDMA and TDMA. TSMP is based on TDMA.

Timeslots and Frames In TSMP, each communication window is called a timeslot. A series of timeslots makes up a frame, which repeats for the life of network. Frame length is counted in slots and is a configurable parameter. In this way a particular refresh rate is established for the network.

A shorter frame length increases refresh rate, increasing effective bandwidth and increasing power consumption. Conversely, a longer frame length decreases refresh rate, thereby decreasing bandwidth and decreasing power consumption.

A TSMP node can participate in multiple frames at once allowing it to effectively have multiple refresh rates for different tasks. The concept of slots and frames is illustrated in Figure 1.

Figure 1. TSMP Timeslots and Frames.Synchronization A critical component of any TDMA system is time synchronization. All nodes must share a common sense of time so that they know precisely when to talk, listen, or sleep. This is especially critical in power-constrained applications like WSNs where battery power is often the only option, and changing batteries can be costly and cumbersome.In contrast to beaconing strategies employed by other WSN implementations, TSMP does not begin each frame with a synchronization beacon. Beaconing strategies can require long listen windows which consume power.Instead, TSMP nodes maintain a precise sense of time, and exchange offset information with neighbors to ensure alignment. These offset values ride along in standard ACK messages and cost no extra power or overhead.A common sense of time enables many network virtues: bandwidth can be pre-allocated to ensure extremely reliable transmission and zero self-interference; transmitting nodes can effectively change frequencies on each transmission and the receiving node can keep in lock-step; bandwidth can be added and removed at will in a very predictable and methodical way to accommodate traffic spikes; and many others.

Duty Cycling It is important to note that TSMP nodes are only active in three states: 1) sending a message to a neighbor, 2) listening for a neighbor to talk, and 3) interfacing with an embedded sensor or processor.

For all other times the node is asleep and consuming very low power. In a wireless device the majority (generally >95%) of the total power budget is consumed by the radio, not the processor.

To achieve low power, it is clear that one must minimize radio on time. TDMA is very good at this. Timeslots are measured in milliseconds and in typical WSN applications this leads to a duty cycle of less than 1% for all nodes in the network (including those relaying messages for neighbors).

Because all nodes (including those often called .routers.) can be aggressively duty cycled, TDMA is the only practical solution for a fully battery-powered network.

In addition to slicing the wireless media across time, TSMP also slices it across frequency. This provides robust fault tolerance in the face of common RF interferers as well as providing a tremendous increase in effective bandwidth.

Commonly referred to as Frequency Hopping Spread Spectrum (FHSS), hopping across multiple frequencies is a proven way to sidestep interference and overcome RF challenges with agility rather than brute force.

Another technique to overcome RF challenges is Direct Sequence Spread Spectrum (DSSS). DSSS provides a few dB of coding gain and some improvement in multi-path fading. While beneficial, DSSS is not sufficient in the face of common interferers in the band, including Wi-Fi equipment, two-way radios or even Bluetooth (see figure 2 below).

Figure 2. Frequency Hopping vs. DSSS in 802.15.4 Networks. It should be noted that a combination of FHSS and DSSS provides both interference rejection (FHSS) and the coding gain (DSSS).The other technique for overcoming interference is increasing the radio power, effectively turning up the volume. Although often effective, turning up the volume on IEEE 802.15.4 radios kills battery life and is not an ideal solution for low-power WSNs.Hopping Sequence Upon joining a network, a TSMP node (call it node C) will discover available neighbors and establish communication with at least two nodes already in the network, call them parent A and parent B (more on this in later sections).During this process node C will receive synchronization information and a frequency hopping sequence from both parent A and parent B. The IEEE 802.15.4 standard specifies 16 distinct frequency channels within the 2.4000-2.4835 MHz ISM band . so let’s use 16 as our number. The hopping sequence is a pseudo-random sequence of all available channels. For example the sequence may be: 4,15,9,7,13,2,16,8,1,etc.

Node C receives a distinct start point in the sequence from each parent, and when a new node joins it, it will in turn give a distinct start point to this new child node. In this way each pair-wise connection is ensured to be on a different channel during each timeslot enabling broad use of the available band in any one location.

In operation, each node-to-node transmission (say C to A) is on a different frequency than the previous transmission. And should a transmission be blocked, the next transmission will be to an alternate parent (C to B) on a different frequency. The result is simple but extremely resilient in the face of typical RF interferers.

Posted in Time Division Multiple Access (TDMA), Media Access Control (MAC), IEEE 802.15.4, Time Synchronized Mesh Protocol (TSMP), Bluetooth, Wireless sensor networks (WSNs), Wi-Fi | No Comments »

Sorting through the embedded WiFi confusion

09/06/2009 by David Slade.

Wi-Fi networking is becoming more popular for embedded applications for much the same reasons as Ethernet networking became popular. The technology is familiar; the equipment to set up the network is inexpensive; and it enables easy communication with PCs and other devices on existing network infrastructure. However, implementing Wi-Fi networking for embedded systems poses some special challenges for the embedded systems designer. Which features should you look for? Which are most important? What special considerations should you be aware of? This article aims to help you understand the peculiarities of Wi-Fi for embedded systems so that you can choose the best Wi-Fi implementation based on your needs.

To determine if a particular embedded Wi-Fi solution is right for you, a number of questions need to be posed and answered. This article covers these questions:

• Does the solution provide full Wi-Fi access (including access to socket-level programming) or simply serial-to-Wi-Fi?

• Will the Wi-Fi solution be available long-term? What issues can you expect over the long-term?

• Is 802.11g or 802.11n supported, or only 802.11b?

• Which security (encryption and authentication) features are supported?

• Is the solution FCC-certified? Can you integrate the solution into your product without additional certification?

• What about certification with other regional authorities? Is multidomain (802.11d) supported?

• What is the maximum data throughput for the solution? How does Wi-Fi encryption and authentication affect your throughput?

• What is the power usage of your Wi-Fi solution? Are low-power modes supported?

• Does it provide typical Wi-Fi range, or is performance compromised?

• What is the operating temperature specification?

• How is antenna placement handled, and can you use an antenna other than that which is provided?

• Is roaming from one access point to another handled cleanly?

Each of these questions will be explored in turn. By studying these questions and researching the answers based on your requirements and the Wi-Fi solutions you’re exploring, you should be much closer to selecting the right solution for your product.

Serial-to-Wi-Fi or full access?
Many Wi-Fi devices for embedded systems provide only serial-to-Wi-Fi functionality. The idea is that the Wi-Fi device has preloaded firmware, and you use a serial port on your embedded device to interface with the Wi-Fi device. This is very similar to serial-to-Ethernet devices. Serial-to-Wi-Fi devices make it easy to add some limited Wi-Fi capability to existing embedded devices (as long as a serial port is available). This option works well for applications that need only one connection (or socket) at a time. It is especially well-suited for allowing a serial port to be accessed over the network. If you need the ability to run multiple servers or clients on your device (such as a web server, FTP server, and email client), serial-to-Wi-Fi devices probably will not provide enough flexibility.

An increasing number of single-board computers and core modules are available that have Wi-Fi integrated as a native network interface. The native network interface typically allows full socket-level access so that you can run concurrent servers and clients–in other words, a full networking system. This can make for an overall cheaper solution since a separate device is not needed. Of course, if you are adding Wi-Fi capabilities to an existing system, the serial-to-Wi-Fi devices will be much easier to implement as long as the limitations are acceptable.

Posted in Wi-Fi | No Comments »

Near Field Communication: Ready For Take Off

09/06/2009 by David Slade.

In 2002, NXP Semiconductors and Sony co-invented Near Field Communication (NFC), a short-range wireless connectivity technology that provides consumers with simple and secure, intuitive and convenient interaction between a variety of electronic devices, such as mobile phones, computers and digital cameras. Examples of NFC use cases include mobile phones that enable payment and ticketing as well as digital cameras that send their photos to a TV set with a simple tap. NFC evolved from a combination of contactless identification and interconnection technology, operating in 13.56MHz frequency range and over a distance of a few centimeters and was standardized by International Organization for Standardization (ISO) and European Computer Manufacturers Association (ECMA) in 2004.

Since its early days, NFC has garnered major interest from various industries. In an effort to advance the use of the technology NXP, Nokia and Sony joined forces and established the NFC Forum in 2004, focused on developing specifications, ensuring interoperability between devices and services and educating the market about NFC. More than 150 member companies make up the Forum today, including semiconductor, handset, PC and consumer electronics manufacturers, applications developers, financial services institutions, among others.

The struggle for standardization
Early days of NFC adoption lacked technical standards and cooperation among numerous ecosystem players, and were faced with market misconceptions. That said, business model discussions and the struggle to finalize standardization of the technology have yielded great progress addressing the needs and ambitions of the various players within the NFC mobile ecosystem. More than 200 NFC projects have been conducted worldwide to date, including trials and commercial deployments with varying use cases of the technology, all of which have resulted in strong adoption and positive feedback from users about NFC’s ease-of-use.

Recently, NFC players successfully standardized the NFC SIM interface at European Telecommunications Standards Institute (ETSI). This Single Wire Protocol (SWP) provides the interface between the SIM card and the NFC chipset on the hardware layer, and enables the hosting of contactless applications securely in SIM cards of mobile phones, a key request from mobile networks operators.

NXP has actively supported and contributed to the development of a definition of a common SWP standard that is fully compliant with the existing contactless infrastructure. Additionally, the software layer for NFC applications, the Host Controller interface (HCI), has been standardized. The first products using these standards, such as the Nokia 6216, have recently been announced (http://www.nokia.com/A4136001?newsid=1307541), and will be commercially available in the second half of 2009.

The leap forward with NXP’s PN544
Leveraging its leadership and expertise in NFC, NXP has presented the world’s first industry standard NFC controller with the company’s launch of the PN544. The PN544 delivers a fully compliant standards-based for handset manufacturers and operators developing next generation NFC devices and services, and is based on the latest NFC specifications by ETSI.

The PN544 is fully compliant with all released NFC specifications on the SWP connection with the SIM and the Host Controller Interface. In addition, NXP worked closely with leading SIM card manufacturers, including Gemalto, Oberthur Technologies and Giesecke & Devrient, to ensure SWP interface interoperability including support of the MIFARE technology. The new NFC controller is fully backwards compatible and interoperable with existing contactless infrastructure for payments and ticketing (e.g. MIFARE), already in place across the world.

To meet the needs of differing handset manufacturers, the PN544 has been designed to support the three main architectures used to secure NFC transactions, including the Secure Element within the Universal Integrated Card (UICC), within the SD card and within the mobile handset (embedded Secure Element: PN544 plus Smart MX security in a pin to pin compliant solution).

The PN544 also features optimized antenna designs for best-in-class performance and a small footprint for size optimization in various electronic device architectures. The controller is specifically designed for low power consumption and works with energy from the field if the handset battery power is low or off. NXP offers the PN544 together with an optional modular, generic and platform independent software stack. To shorten the integration time, NXP also offers qualified design-in support.

The way forward for NFC
With standardization issues resolved, mobile handset makers can take advantage of the compliant chipsets, and can begin producing NFC handsets in larger volumes. Major handset manufacturers are currently NXP’s PN544 to ramp up their production, and new standard compliant NFC devices should be available in the second half of 2009.

This development will bring NFC-enabled phones to consumers in large volumes, so they can take advantage of the ease, speed and convenience offered by the technology. Leading handset manufacturers have indicated plans to incorporate NFC as a standard feature into their cell phone platforms, comparable with today.

With large contactless infrastructure already in place, it is expected that commercial deployments will initially focus on contactless payment in Northern America and on ticketing in Asia and Europe. The arrival of NFC handsets and other NFC-enabled devices will advance the adoption of NFC and boost the launch of new contactless applications and services in the markets around the globe.

Posted in contactless infrastructure, Universal Integrated Card (UICC), Near Field Communication, Uncategorized | No Comments »