Including Optional Software Components In Deployment Optimization Algorithms A Proposal to the Virginia Space Grant Consortium Prepared by: Hamilton Turner Feb 2011 1 Background Emerging Trends and Challenges. Fly-by-wire aircraft, the International Space Station, and the Lunar Reconnaissance Orbiter are all examples of distributed real-time and embedded systems, where wired or wireless networks are used to interconnect real-time and embedded systems, such as flight con- trol systems and sensory systems. Although real-time embedded systems have been historically relatively small-scale, recent trends have vastly increased the number of components and interconnections for many DRE systems, such as lunar robotics systems. Sen- sor platforms can have 10’s or 100’s of processing units, spatially separated on several physical plat- forms, connected through multiple ad-hoc network links between processors, and executing several hun- dred software components[5]. The deployment topology, which controls the map- ping of software components to hardware processors, has traditionally been dictated in an a priori man- ner due to a tight coupling of software and underly- ing hardware. However, recent trends in DRE sys- tems have advanced decoupling of the software from the underlying hardware, using a variety of standard runtime interfaces such as the CORBA framework[4]. For example, fractionated spacecraft systems [1] have been designed that work cooperatively and indepen- dently of the underlying hardware [3]. Typical complex system development has had to limit software components to one of two categories - software that will be deployed, and software that will not, due to hardware resource limits. However, software components which are useful in one context, such as during the launch of a satellite into orbit, are often not useful during other system states, resulting in under-utilized hardware. Therefore, a run-time re- deployment could be used to replace less relevant soft- ware components with other, more relevant, compo- nents that increase the functionality or performance of the system, such as data compression or advanced signal processing libraries. These additional software components would be optional (e.g. beneficial but not absolutely necessary for system operation), and their potential benefit could be changed at runtime in a context-dependent manner, such as increasing the benefit of an advanced signal processing algorithm when weather causes above- average noise levels in incoming signals. The feasibility of using run-time re-deployment as a method of changing system func- tionality and increasing performance is based in three key points: • deployment topology has been shown to have a large impact on system performance, • various methods have been developed to en- sure that deployment topologies will not inval- idate any system constraints, such as real-time scheduling, • and recent advances in using heuris- tic/metaheuristic algorithms to perform 1