Hi All, I just would like to add that Julio and I are going demonstrate the described solution at the software-centric system conference in Eindhoven (Netherlands) next week (25 may) [1]. A tad late, but you are welcome visit us at the conference :)
[1] http://softwarecentricsystems.com/session/a-demonstration-of-a-dynamic-reconfigurable-software-architecture/ Greetings, Pepijn On Fri, May 13, 2016 at 9:40 AM, Oliveira Filho, J.A. (Julio) de < [email protected]> wrote: > Dear APACHE ACE team, > > > > Last years, our teams at TNO and Thales have been working on technologies > for dynamic composition of software modules and adaptive deployment of > software architectures. The functionalities we developed allow systems to > define -- at runtime -- which software components should be deployed and in > which computing resources. System design and deployment decisions are > based on the current goal of the system, the actual availability of > resources, and the desired computing performance. This allows us for > example, to build systems that react to failing machines by re-deploying > software modules in healthy resources. It also allows to dynamically > share, bind, and re-deploy software modules when new functionality is > introduced in the system. All that taking into consideration the computing > resources available and for example, how their load will be after the > system deployment. > > > > *We believe many of the technologies we developed could also be of value > for the APACHE community, and in special the APACHE ACE community*. > Moreover, this would help us to possibly get a broader user base and > development incentive. For this reason, we get in contact with you. > > We summarize our innovations in two aspects that we believe add value for > the APACHE ACE community: > > > > 1. We extend the requirement-capability model of OSGI (used in ACE) > to go beyond dependencies between software modules (bundles). In specific, > we introduced simple but effective concepts in this model that enable > software designers to: > > a. describe dependencies of software modules to physical computing > resources. For example, it is possible to explicitly describe the required > amount of memory, or the required use of special hardware, such as GPUs and > graphical boards. A language model creates a standard for interoperability > and semantic understanding. > > b. describe virtual software modules representing higher abstraction > levels of composition. For example, it is possible to describe a signal > processing chain as composed by a sampler module, a filtering module, and a > detection module. At this level, the dependencies in the chain are > resolved based on what they do and their performance level (accuracy, > resolution, etc.), but not yet on implementation details, such as their > interface. High abstract modules are resolved hierarchically into possible > concrete implementations, which in turn provide the more specific > dependency aspects such as the interface and the required physical > resources. > > > > 2. We extend the functionality of the OSGi Resolver with the > following features : > > a. we resolve requirement-capability constraints that takes into > consideration the physical resources available. At our system, software > requirements to computing resources (memory, cpu, special hardware) are > resolved against special bundles/models that represent the (current) > capabilities of the available hardware; In these cases, we not only > produce a resolved module composition, but we guarantee that it can be > deployed in the currently available hardware. > > b. we consider the physical allocation of software components to > computing resources as part of the resolution process. In other words, we > extended the resolution role to also determine where each software > component should be deployed. > > c. we consider many possible solutions from the resolver at the > same time, instead of the default behavior of the OSGI resolver that > returns only the first feasible resolved solution back (or fail). The > fittest solution is chosen among the several produced according to a > customizable goal function -- for example, which system has the best > response-time. > > d. the resolution step can optimize the physical deployment of > software components based on a customizable goal function -- for example, > by prioritizing deployments that balance the load among the available > resources against deployments that overload a single machine. > > > > We believe the features above are an added value in the following > situations: > > · Deployments of software components in heterogeneous resource > environments, such as the cloud, embedded or high-performance specialized > platforms, and interoperability hardware hubs. > > · Deployments of software components in unreliable environments > where failing resources and communication links often happen -- examples > could be ad-hoc installations, embedded and distributed platforms > (Internet-of-Things); > > · Gradual deployments of software components, where > functionalities are included on demand, but with risk of overloading the > computing resources; > > > > *We are curious to know if the APACHE ACE community would be interested in > adopting these ideas. We would gladly demonstrate and discuss with you > future possibilities. What do you guys think about the ideas above? Would > they be of added value to ACE?* > > > > Last, but not least, we would like to say a few words about ourselves. > > > > Julio Oliveira, Bardo Bakker, and Maarten Ditzel are specialists on > distributed and networked embedded systems for TNO. TNO is involved in the > design and development of innovative software and hardware platforms, that > use dynamic reconfiguration to improve their reliability, power > consumption, or efficiency. Within this work TNO co-designed and > co-implemented the mechanisms for dynamic functional composition and > resource allocation. > > > > Pepijn Noltes, Rene van Hees, and Hans Schurer are software architects at > Thales Nederland and have been involved in different research projects > oriented around dynamic reconfigurable systems. The Thales team has a > special interest in software evolution and time-critical systems. Pepijn > Noltes himself is already a committer for the Apache Celix project. > > > > We look forward for hearing from you how we can continue this discussion. > > > > Sincerely, > > > > Julio A. de Oliveira Filho > > > > > > > > Dr.Rer.Nat. J.A. (Julio) de Oliveira Filho > Innovator > DSS/Technical Sciences > > T +31 (0)88 866 31 23 > M +31 (0)64 684 73 73 > E [email protected] > > Location <http://www.tno.nl/locaties/DHW> Den Haag > > > > <http://www.tno.nl/> > > This message may contain information that is not intended for you. If you > are not the addressee or if this message was sent to you by mistake, you > are requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use > it and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages. > > > > *Please note when visiting TNO Waalsdorperweg:* > > In compliance with the strict security regulations for this location, the > security staff will ask you to leave your smartphones with camera in the > lockers available at the reception desk. > > >
