In embedded and device software development, the end product can contain multiple targets. Each target can contain multiple processors, and each processor can contain multiple cores. The application software running on a core can contain multiple processes and threads.

Each of the entities can often be independently controlled. Targets can be located in a developer's office, in a board lab, or even deployed in the field. A single target may have multiple control channels, such as local serial or JTAG connections or remote socket connections.

The mission of the Eclipse.org Target Management (TM) subproject is to create data models and frameworks to configure and manage these systems, their connections, and their services. Target Management intends to support downloading software and data, launching single or multiple configurations, starting and stopping cores, debugging processes and threads, querying target information, etc.

Technical Plans
The TM project is building its initial design on an established technology developed by IBM called Remote Systems Explorer (RSE), which at the time of this writing is in the process of being released into open source: www.developer.ibm.com/isv/rational/remote_system_explorer.html. RSE provides a data model for describing remote systems, a framework for dealing with remote system connections and subsystems, and a feature-rich GUI for visualizing and interacting with remote systems. A screen capture of RSE is shown in Figure 1 below.

Figure 1

The existing RSE architecture can be extended using plug-ins in the following ways:

1) SystemType extension point " This extension point provides the ability to add new kinds of remote systems that can be accessed by a variety of methods. RSE currently uses a protocol called "Datastore" that requires a portable server running on the remote system. The TM project will work on additional system types for standard protocols like FTP and ssh to address the needs of embedded targets.

2) Subsystem extension point " This extension point provides the ability to define an interface for additional kinds of resources on a remote system. The current RSE product has subsystems for remote filesystems, remote shells, and remote processes. The TM project will add additional device software centric subsystems, e.g. visualization of target OS kernel objects like semaphores and queues.

3) PropertyPages extension point " This extension point provides the ability to define visualizations for additional properties of remote resources. The current RSE product has property pages for remote files and remote processes. The TM project will add additional property pages for new types of remote embedded target resources.

4) Actions extension point " This extension point provides the ability to define actions on remote resources. The current RSE has actions for searching remote file systems and for arbitrary user-defined shell commands. The TM project will add additional actions typically required for embedded targets like remote reboot and kernel module download.

In addition, RSE allows contributing wizard pages for defining remote system properties and provides reusable widgets that give access to remote resources in a manner very similar to working with resources on a local system.

Using RSE as the foundation and starting point, the TM project intends to provide a framework for vendor-supplied pluggable target services such as:

1) OS-aware Services
    a) Remote File System (for File download)
    b) Remote Process Explorer (Query target info, Kernel Objects)
    c) Kernel Module Downloads
2) Generic Services not necessarily dependent on an OS
    a) Remote Console (Serial, TCP/IP)
    b) Reset / Reboot (Start and Stop Cores)
    c) RAM download of arbitrary images (e.g. via JTAG)
    d) Flash programming utility
    e) Debugger Launcher

Shown in Figure 2 below is a block diagram of the future Target Management architecture based on RSE. The specifics of this architecture are still in design, but we will describe a few of the planned capabilities.

Figure 2

Launch Actions. Launching an application on a remote system often involves a complex sequence of actions like downloading code and data to one or more remote nodes, resetting one or more the nodes, etc. In order to address these needs, the TM project will define a flexible Launch Sequencer that can be extended by contributing Launch actions from external plug-ins.

Target Connection Adapters. Developers of Device Software often have to deal with hardware from multiple vendors, and each vendor may employ a different protocol to access the remote system.

The hardware vendors, however, do not necessarily want to provide a complete protocol stack for their target; instead they would prefer to plug in the vendor-specific portions of their protocol into a framework that handles the rest of the communication stack.

To satisfy this need for pluggable componentized communication channels, TM envisions creating Target Connection Adapters, or what we will call "Connectors" for short. A connector, as illustrated in Figure 3 below is an Eclipse plug-in that contains:

1) the implementation of the required framework interfaces to control and manage the connector
2) the implementation of the required application interfaces to communicate with the target system
3) the implementation of the communication to the target system
4) the implementation for storing and retrieving dynamic information
5) the implementation of the detailed views for the general Eclipse remote connection view (shown in the blue dotted line below)

Figure 3

Connectors can be configured manually by the user, but future releases of the TM framework will also contain a component for automatic configuration of connectors based on auto-detection of static and dynamic connector information. We refer to this as "Connector Plumbing".

Auto-detection. Target connection interfaces will include methods to automatically detect available services and protocols on the remote systems. Connection Groups.

When managing remote systems that consist of multiple sub-systems, e.g. multiple cores on a hardware target, it is desirable to define groups of connections such that individual actions like reset or download can be performed on a group in a single step. The TM project will extend RSE with the ability to define connection groups.

Access Control. Remote Systems can be organized in a variety of ways, including targets that are deployed at a remote site (but still need to be available for tasks like online update), or targets that are organized in a shared development board lab. For these use-cases, TM will provide an extensible component for scheduling and access control.

Finally, in order to release some useful functionality to the open source community as soon as possible, TM intends to provide a Remote Application Launch capability for CDT based on the existing RSE technology. Remote Application Launch will use TM Services to generalize the way remote system properties are accessed, as shown in the block diagram in Figure 4 below.

Figure 4

By using this new Remote Launch, CDT users will get a unified look-and-feel for accessing remote systems. Moreover, vendors that build on top of CDT can get access to additional services and connection types for new kinds of remote systems contributed by third parties.

<>Release Plans and Next Steps for TM
The Target Management subproject currently has four milestones planned:
Milestone 1 (January 2006)
       1) RSE released to open source

Milestone 2 (Same timeframe as Eclipse 3.2 - end of June)
       1) CDT Integration
       2) Target Definition & Selection, "Remote Debug" Launch configuration

Milestone 3 (TBD)
       1) Standards-based target connections (FTP, Telnet, ssh?)
       2) "Download" and "Run" Launch actions based on above services

Milestone 4 (TBD)
      1) Open Connectors for HW Debuggers (Preconfigured Connection Types only)
      2) Connection Model for HW Debugging (complex connector setup)
3) Flexible Launch Scripts

Additional Milestones
1) Extend connectors with a framework for more remote target connection modularity beyond the existing RSE capabilities today.
      a) Use the Eclipse Communication Framework (ECF)
      b) Add more protocol support (ssh, )
      c) Provide a framework for auto-detecting available services and protocols

2) Build Launch Actions and Launch Sequencer.
      a) Create a "Custom Remote Launch" that is composed of arbitrary actions, e.g. configure, download, reset, start, etc., which are contributed via extension points.
      b) Make launches behave like a "script" to run against one or more targets.
      c) Create "Connection Groups" for controlling multiple targets at the same time
      d) Build a framework for the managing and controlling target access to boards in a board lab.

Doug Gaff is engineering manager on Wind River's commercial Eclipse-based device software suite and PMC Lead for the Eclipse.org Device Software Development Platform (DSDP). 

This article is excerpted from a paper of the same name presented at the Embedded Systems Conference Silicon Valley 2006. Used with permission of the Embedded Systems Conference. For more information, please visit www.embedded.com/esc/sv.