The Eclipse Device Software Development Platform: Target Management -

The Eclipse Device Software Development Platform: Target Management


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

Each of the entities can often be independently controlled. Targetscan be located in a developer's office, in a board lab, or evendeployed in the field. A single target may have multiple controlchannels, such as local serial or JTAG connections or remote socketconnections.

The mission of the TargetManagement (TM) subproject is to create data models andframeworks to configure and manage these systems, their connections,and their services. Target Management intends to support downloadingsoftware and data, launching single or multiple configurations,starting and stopping cores, debugging processes and threads, queryingtarget information, etc.

Technical Plans
The TM project is building its initial design on an establishedtechnology developed by IBM called Remote Systems Explorer (RSE), whichat the time of this writing is in the process of being released intoopen RSEprovides a data model for describing remote systems, a framework fordealing with remote system connections and subsystems, and afeature-rich GUI for visualizing and interacting with remote systems. Ascreen capture of RSE is shown in Figure1 below.


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

1) SystemType extension point ” This extension point provides the ability to add new kinds of remotesystems that can be accessed by a variety of methods. RSE currentlyuses a protocol called “Datastore” that requires a portable serverrunning on the remote system. The TM project will work on additionalsystem types for standard protocols like FTP and ssh to address theneeds of embedded targets.

2) Subsystem extension point ” This extension point provides the ability to define an interface foradditional kinds of resources on a remote system. The current RSEproduct has subsystems for remote filesystems, remote shells, andremote processes. The TM project will add additional device softwarecentric subsystems, e.g. visualization of target OS kernel objects likesemaphores and queues.

3) PropertyPages extension point ” This extension point provides the ability to define visualizationsfor additional properties of remote resources. The current RSE producthas property pages for remote files and remote processes. The TMproject will add additional property pages for new types of remoteembedded target resources.

4) Actions extension point “This extension point provides the ability to define actions on remoteresources. The current RSE has actions for searching remote filesystems and for arbitrary user-defined shell commands. The TM projectwill add additional actions typically required for embedded targetslike remote reboot and kernel module download.

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

Using RSE as the foundation and starting point, the TM projectintends to provide a framework for vendor-supplied pluggable targetservices such as:

1) OS-aware Services
    a) RemoteFile System (for File download)
    b) RemoteProcess Explorer (Query target info, Kernel Objects)
    c) KernelModule Downloads
2) Generic Services notnecessarily dependent on an OS
    a) RemoteConsole (Serial, TCP/IP)
    b) Reset /Reboot (Start and Stop Cores)
    c) RAMdownload of arbitrary images (e.g. via JTAG)
    d) Flashprogramming utility
    e) DebuggerLauncher

Shown in Figure 2 below isa block diagram of the future Target Management architecture based onRSE. The specifics of this architecture are still in design, but wewill describe a few of the planned capabilities.


Launch Actions . Launching anapplication on a remote system often involves a complex sequence ofactions 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 beextended by contributing Launch actions from external plug-ins.

Target Connection Adapters. Developersof Device Software often have to deal with hardware from multiplevendors, and each vendor may employ a different protocol to access theremote system.

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

To satisfy this need for pluggable componentized communicationchannels, TM envisions creating Target Connection Adapters, or what wewill call “Connectors” for short. A connector, as illustrated in Figure 3 below is an Eclipseplug-in that contains:

1) the implementation of therequired framework interfaces to control and manage the connector
2) the implementation of therequired application interfaces to communicate with the target system
3) the implementation of thecommunication to the target system
4) the implementation forstoring and retrieving dynamic information
5) the implementation of thedetailed views for the general Eclipse remote connection view (shown in theblue dotted linebelow )


Connectors can be configured manually by the user, but futurereleases of the TM framework will also contain a component forautomatic configuration of connectors based on auto-detection of staticand dynamic connector information. We refer to this as “ConnectorPlumbing”.

Auto-detection. Targetconnection interfaces will include methods to automatically detectavailable services and protocols on the remote systems. ConnectionGroups.

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

Access Control. RemoteSystems can be organized in a variety of ways, including targets thatare deployed at a remote site (but still need to be available for taskslike online update), or targets that are organized in a shareddevelopment board lab. For these use-cases, TM will provide anextensible component for scheduling and access control.

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


By using this new Remote Launch, CDT users will get a unifiedlook-and-feel for accessing remote systems. Moreover, vendors thatbuild on top of CDT can get access to additional services andconnection types for new kinds of remote systems contributed by thirdparties.

<>DSDP PanelRelease 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 timeframeas 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 aframework for more remote target connection modularity beyond theexisting RSE capabilities today.
      a) Usethe 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 andLaunch Sequencer.
      a) Createa “Custom Remote Launch” that is composed of arbitrary actions, e.g.configure, download, reset, start, etc., which are contributed viaextension points.
      b) Makelaunches behave like a “script” to run against one or more targets.
      c) Create “Connection Groups” for controlling multiple targets at the sametime
      d) Build a framework for the managing and controlling target access toboards in a board lab.

DougGaff is engineering manager on WindRiver's commercial Eclipse-based device software suite and PMC Leadfor the DeviceSoftware Development Platform (DSDP).  

This article is excerpted from apaper of the same name presented at the Embedded Systems ConferenceSilicon Valley 2006. Used with permission of the Embedded SystemsConference. For more information, please visit

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.