Skip navigation
2010

Defining an untethered device is an interesting task. For some, untethered means a portable computer that relies on a wireless connection to other computers.  But untethered also means medical devices placed into the human body for diagnostic purposes, a semiconductor that includes an antenna and communication circuitry, wireless communication equipment for factory automation, mine tracking equipment for safety,  and much more. Untethered evidently really refers to a technical capability and not to a traditional market segmentation.

Until fairly recently, most untethered devices used proprietary communications and closed Operating Systems (OSes). One of the beliefs that fostered the proprietary systems approach was the mistaken idea that using a closed system provided better security than common general purpose OSes. Obscure OSes held little reputation-building potential for hackers, so they focused their attention on mass market systems using a common OS such as Windows.  Now we’re in the midst of fundamental changes. Systems experts have recognized that obscure doesn’t mean secure. While other changes are based on a systems philosophy that not only embraces popular OSes, but also adopts Open Software – the ultimate in transparency . 

 

As untethered devices become the norm in a wide variety of applications employing a common OS and open source tools/applications, securing the mobile unit is required to ensure safety of people, data and equipment.  One industry market researcher predicts that engineers will not have the tools necessary to achieve this goal until 2012. However, much of the required fundamental infrastructure is in place today.

 

Chief among the untethered applications requiring security are Medical, Industrial, Military, and retail. First responders will use the latest embedded technologies in mobile diagnostic equipment  to securely transmit diagnostic data in real time to medical professionals. Intelligent multi-axis mobile robots will employ 3D machine vision and video analytics software to improve manufacturing factory floor efficiency while simultaneously assuring safety for people. New terminals will help bring low-cost banking services to remote locations. All of these embedded applications either already rely on, or will rely on, Internet Protocol technology for communication. Securing the communications channel is a key part of securing an embedded device.

 

The boot process is the beginning of securing an embedded system. Systems that are non-reprogrammable have one of the lowest native security risks possible because there’s relatively little opportunity for exploiting simple software attacks. This fact does not lessen the need for security in these systems because many non-reprogrammable systems are vulnerable to theft which gi ves hackers complete access to the device. In this case, physical hardware hacks join the more traditional software attack as methods of breaking into the system.

 

For systems in which applications software can be loaded onto the system, the security risks increase. Many different attacks on systems begin during the boot process. Intel’s Trusted eXecution Technology (TXT) provides developers with a configurable boot process that minimizes chances for corruption. The basics of TXT were explored in an earlier blog.  When supported by an Intel processor with required hardware support, TXT provides a first, fundamental line of defense against hacking and attempts by unauthorized people from compromising the system.

 

Beyond the boot process, software isolation is one technique to improve security. Virtualization adds an additional layer of software to the system. Green Hills® Software, an Affiliate member of Intel® Embedded Alliance,  provides software designed to work with Intel Virtualization Technology hardware support, when present in the processor, to isolate applications software and kernel functions. This provides the highest degree of security currently possible.

 

Regardless of how virtualization is implemented and used, it is always necessary for an additional layer of software to be part of the overall system. This additional layer schedules the operating systems which share the hardware platform, manages the resources assigned to each OS, and saves/restores state when context switching between the OSes. In this way each OS executes within a "virtual machine" (VM) rather than on a physical machine. This additional layer of software, the Virtual Machine Monitor (VMM), manages the execution of OSes. A more detailed treatment of VMMs for embedded systems is available at http://www.intel.com/technology/itj/2006/v10i3/5-communications/1-abstract.htm

 

197i85EE43F344D7545B

Green Hills Software’s INTEGRITY® can host a wide range of guest operating systems in Padded Cell™s and simultaneously hosting safety and security-critical native INTEGRITY® applications. Using this model allows developers to maintain real-time performance and protect critical applications from other applications. Guest operating systems may include Alliance  Associate member Wind River Systems’ VxWorks, BSD, Red Hat Linux,  Alliance  Associate Sun Microsystems Solaris, and Alliance Associate Microsoft®’s Windows®. For example, Windows or Linux can be hosted on Padded Cell® virtual machines where they can be protected and isolated from common security threats. For industrial control and automation, INTEGRITY® Padded Cell™ supports retrofitting these systems to make them resistant to attack. Of course, newly developed Industrial Control and Automation applications can be developed to gain a greater advantage by relying on virtualization techniques as a fundamental part of the design.

For untethered embedded systems that rely on a server for all or part of its functionality, there are OSes that can be configured to reduce their footprint and only provide server services necessary for the whole embedded system. Microsoft Windows 2008 R2 server software can be configured in a minimal footprint in a server-client system.  When configured as an embedded server, Windows 2008 is designed to:

 

  • Protect your network against unauthorized or unhealthy computers
  • Deploy small footprint specialized servers
  • Achieve more highly secure server communication
  • Reduce server attack surfaces
  • Provide best-of-breed data encryption

Design decisions for embedded applications that require security depend heavily on the actual applications. In this blog we’ve examined a number of alternative and options for securing untethered applications from data vulnerabilities and hijacking of the platform through software attack.

Intel Virtualization, whether for realtime systems or not provides embedded systems with a wide selection of techniques to insulate the system from outside attack. Physical loss of the embedded device by a user is still a risk to be managed. But like the standardized TXT technology, there are other ways to guard against unauthorized access under those conditions that are outside the scope of this blog.

 

What applications are you developing that need enhanced security?

Embedded system designers today have a plethora of off-the-shelf computing platforms in a variety of form factors that feature multiple cores per processor, sometimes multiple processors per board, and in many instances the processors are capable of multithreaded operation. But how do embedded design teams easily leverage the available computing resources? Certainly teams can develop parallel structures in carefully-coded embedded applications, although many teams lack multithreading expertise. The broad proliferation of Intel Architecture multi-core technology has created momentum across the embedded space resulting in far simpler development options relative to other processor architectures. For Instance, a graphical tool such as National Instruments* LabView allows engineers that lack multithreading programming experience to quickly develop applications using a dataflow approach that takes advantage of the multi-core trend.

 

While LabView’s roots are in the test and measurement area, the graphical programming environment finds use today in a variety of embedded applications including real-time control and as a product development and prototyping tool. Teams can use LabView both with hardware offered by National Instruments and with board and system level products from a variety of third parties. Teams will find off-the-shelf hardware modules for applications ranging from data acquisition to visualization to communications. For instance, you can easily prototype a cellular base station using LabView software and off-the-shelf hardware modules.

 

National Instruments added multithreading support to LabView 5.0 back in the late 1990’s after the advent of multithreaded processors but before multi-core processors were available. Casey Weltzin, LabView Real Time Product Marketing Engineer, states, “We chose to support multithreading so that we could ensure both a very responsive user interface and very responsive program code.” From inception, LabView has combined a graphical user interface with the ability to create and execute software-based functions that might or might not rely on hardware that connects to the real world.

 

LabView is generally considered to be a dataflow programming language or environment. Users typically define a program based on inputs flowing into computation functions with the results driving outputs. Clearly that’s an over simplification because LabView certainly supports feedback, loops, and the ability to accept user input and display results. But the graphical development tool is generally based on dataflow (See the example screen shot below that shows part of the graphical program representation in the right portion of the screen and the UI in the left portion).

 

185i6181902EFF1168AF

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Both the internal multithreading support in LabView and the dataflow programming model combine to optimize code execution on multi-core targets. Weltzin points out that the data-flow code-definition process naturally results in users defining parallel software functions that operate on parallel data. And at run time, LabView attempts to find all parts of the code that can run in parallel. Weltzin relates that the LabView teams calls these objects lumps, although the industry might call them tasks. LabView identifies the number of available cores, examines the lumps, and breaks the code into the optimum number of threads for fastest execution.

 

Here are several additional resources if you would like to learn more about the multi-core capabilities in LabView. Learn why dataflow languages map well to multi-core processors. You can get more help on handling multi-core designs with LabView. And the latest revision of LabView offers some dedicated tools to boost multi-core performance.

 

You might also want to peruse some case studies that demonstrate the advantage LabView brings to multi-core designs. The Max Planck Institute in Germany has used LabView and multi-core processors in its Fusion research. The result was a factor five improvement in matrix multiplications required for real-time loop control.

 

Eaton, meanwhile, used a multi-core approach and LabView in a truck transmission testing system. The combination quadrupled the number of data channels that the system can examine in real time.

 

You might notice that both of the case studies have a real-time component inherent in the quick study. National Instruments does offer LabView Real-Time for applications that require such response. Moreover, you can combine the real-time software, and standard LabView in one system using Intel® Virtualization Technology (Intel® VT) and the National Instruments Hypervisor. Weltzin points out that typical implementations dedicate one core to the user interface on standard LabView and the remaining cores to LabView Real-Time.

 

For more information on Intel multi-core technology and processors, you can peruse a broad look at Intel’s multi-core technology and look specifically at multi-core technology for embedded and communication applications.

 

What approach do you take to multi-core designs to get the most out of the available compute resources? Have you used LabView in a multi-core system? Please share your experience via a comment so that fellow followers of the Intel® Embedded Community can learn from your experience.

 

Maury Wright

Roving Reporter (Intel Contractor)

Intel® Embedded Alliance

 

*National Instruments is an Associate member of the Intel® Embedded Alliance.

 

This is my third blog in a series about JTAG debug for Intel® Architecture (IA) processors.  If you read my previous blogs you would have picked up on my theme that the embedded developer’s debugger options have greatly expanded over the past few months.  For the longest time, the sole choice was Arium.  Then in mid-2009 came alternatives from Wind River and Green Hills.  When Intel decided to enable additional vendors to provide IA debug, it seems to me they did so in a big way.  Joining the three companies I’ve already covered are Macraigor and Lauterbach. My focus of this blog is on Macraigor and I’ll cover Lauterbach in a later one.   Note my choice of sequence here is somewhat arbitrary and nothing should be otherwise inferred.   All five companies mentioned are members of the Intel® Embedded Alliance.  Wind River Systems is an Associate member; Arium, Green Hills Software, and Macraigor Systems are Affiliate members; and Lauterbach GmbH is a General member of the Alliance.    

 

Macraigor’s entry into the IA space is support for Intel Atom™ added to their core product line usb2Demon™ .   One side of the usb2Demon interfaces to a USB 1.1 or USB 2.0 port of a host PC and the other side connects to an OCD (On-Chip Debug) port on the target system. Here are some snippets I pulled from their website: 

 

  • When connected to a USB 2.0 port on your PC, the usb2Demon will run up to Hi-Speed USB rates (480Mb/s).  For Atom on the Crown Beach board, the download rate is 35K Bytes/sec (with JTAG clocked at 24 MHz). 
  • Power is supplied by the USB interface so that no external supply is necessary.
  •  The buffers that interface to the target OCD signals are powered by the target itself, allowing the usb2Demon to automatically match target voltages between 5.0 V and 2.2 V. 
  • As with all Macraigor interface devices, the usb2Demon can simultaneously debug up to 255 devices on a single scan chain.
  • Up to 16 usb2Demons can be connected to a single host machine. 
  • It supports configurable JTAG/BDM clock rates up to 24 MHz. 
  • The usb2Demon is compatible with Windows and Linux hosts. Supported versions of Linux are Red Hat 7.2 – 9 and Fedora Core 2. 
  • It is available now with a 24, 31 or 60 pin interface. 

 

 181iD41436483DC07EA4

 

 

 

The usb2Demon has a list price of $799 which includes various free software components.  A Flash programmer comes at additional cost.  Software support is key but let me address pricing first and I’ll come back to software later…  I think this affordable price point definitely validates the company’s stated positioning of serving the “cost conscious” customer.  It did make me wonder what you get and what you don’t get for this price, compared to the competing tools.  Well for starters, support is presently offered only for Atom, so if you are targeting another IA part this product obviously isn’t for you.   But if you are designing around Atom, for the rest of the answer I went directly to the source – Macraigor’s co-founder and managing partner, James MacGregor. 

 

MacGregor claims that their tool can do everything that the others do with one exception – run-time trace.  His take is trace isn’t all that necessary if your primary task is software bring-up rather than hardware debug, and that their breakpoint functionality is a suitable alternative.  That seems to make sense especially if you are using one of the many commercial board- or module-level products available from the Alliance member companies instead of designing a custom board.  

 

Now I come back to software which is where, according to MacGregor, lies the real differentiator that enables their pricing level.  Rather than investing in developing a proprietary Integrated Development Environment (IDE), they took the approach of leveraging open platforms.  From their website you can download free GNU / Eclipse development environment and tools including assembler, C compiler, debugger, Eclipse environment and over 80 example board specific C/C++ Eclipse/gcc/gdb projects.  In addition to supporting the developer, Macraigor provides a board test product for the production side of the house.  Again leveraging open systems, this package is created in Java, and Eclipse project examples are available for 13 boards, including Crown Beach for Atom.  Java-based means that typical college graduates can get a board test package up and running without the need for special expertise in assembly language.  MacGregor says that customers often achieve this in one day.

 

All four companies I’ve blogged about in this series have a primary focus on software and tools and all have experience in JTAG debug.  Macraigor boasts shipments of 30,000 units over the past 10 years, about half of which were sold directly to customers with the balance shipped in evaluation board kits through OEM relationships with major silicon manufacturers.  Macraigor supports a list of popular embedded processors and developers familiar with the company’s products for those other architectures should find migration to IA an easy transition. 

 

Concluding for now, let me leave you with a current snapshot of the JTAG debug options currently available for IA.  As mentioned above, I plan to come back with another separate blog on Lauterbach.

 

Company

Products

IA Processor Support

Arium

ECM-XDP3

ECM-700

Intel® Core™ 2, Atom™, Pentium®, Celeron®, and Xeon®

Green Hills Software

Green Hills Probe™

Intel® Atom™, Core™ 2, Xeon® 5500 (Nehalem), and EP80579

Lauterbach GmbH

Trace32®

Intel® Atom™

Macraigor Systems

usb2Demon™

Intel® Atom™

Wind River Systems

Wind River Probe

Wind River ICE 2

Intel® Atom™ now, Core™ 2 duo and Xeon® planned

 * Data obtained from the respective company websites at the time of posting  

 

I think a lot of recent strides have been made in tools supporting embedded IA developers.  Would you agree?  What would you like to see next?  If you have an opinion or a specific need please feel free to share it!

 

Felix

 

J. Felix McNulty
Community Moderator
Intel® Embedded Community
(Intel contractor)