| Version 1 (modified by antoni, 14 years ago) |
|---|
ALOE Architecture
The following figure shows the relation between the different ALOE components and libraries. The application software (here represented by a single module) uses the ALOE services to interact with its environment. These services are accessible as function calls; the ALOE software library contains their implementation. The basic operations provided by the software library may require profound platform or hardware management. The ALOE hardware library makes these issues transparent to the software library. It takes advantage of the available hardware services and operating system tools, if present. The ALOE software components (ALOE Software Daemons) are accessed though the ALOE software library and perform several tasks for successfully running a waveform on distributed computing resources. The implementation of these components is platform independent and, hence, directly portable to other platforms (if the hardware library is available on these). A short description of the software daemons and their functionalities follows, where MAN is an acronym for manager.
- CMD MAN: Provides a central access to ALOE for higher level control applications, for instance, including GUIs, text-based commands, software development tools, etc.
- HW MAN: Automates the computing resource management for a dynamic allocation and reallocation of computing resources.
- SW MAN: Administrates the application and component repositories.
- STATS MAN: Provides the initialization parameters of application modules and monitors the evolution of application variables.
- BRIDGE: Acts as a link for data transfers between connected PEs.
- SYNC MAST: Provides the time reference for all PEs.
- FRONT-END: Routes the ALOE control packets among the daemons and gathers the hardware status information.
- SW LOAD: Assigns local resources to modules and their data interfaces.
- EXEC CTRL: Ensures that every software module is correctly running under the given quality of service (QoS) constraints (real-time computing resource requirements).
- STATS: Captures and modifies module variables and parameters.
- SYNC: Synchronizes the local time with the remote time reference.
Cognitive Functionalities
The term cognition refers to the act of knowing or being aware of the (cognitive) entity’s internal or external environment. A cognitive radio is thus a radio that features a set of tools or procedures for detecting the users’ communication needs and for providing radio (and computing) resources that are most appropriate to satisfy these needs. As regards ALOE, we can divide its cognitive functions in two groups:
Computing Resource Management: The system must have information about its current internal status and architecture at any time:
• Plug-and-play network discovering (plugged/un-plugged processors must be recognized automatically on run-time),
• Distributed processing resources management (time, area, power…),
• Processor internal parameters capture (power, battery, malfunctions…) and so on.
Application and Execution Management: This includes the application variables capture and when acting in consequence, its modification;
• Real Time execution surveillance;
• Autonomous application and component repository management, application Stop and Run control, etc.
On the other hand, all cognitive functions are executed by Software Daemons. They are also grouped in two types depending on their “intelligence” level:
Manager Daemons: These are intelligent elements that do not directly access environmental variables or parameters but make decisions as a function of their values and the predefined procedures or methods.
Sensor/Actuator Daemons: These are non-intelligent elements but provide a direct access to envi-ronment variables and parameters. The interaction is bidirectional, allowing capture and modification of values.
ALOE functionalities are illustrated in next figure. Is shows a two-dimensional space where the vertical axis represents the level of intelligence and the horizontal axis the hardware (left) to software (right) space. Note that the non-intelligent entities at the bottom of next figure are not allowed to horizontally communicate with one another. The information they gather is only reported to its immediate manager (the one in charge of it), which governs their actions. This separation is very useful to clarify and understand the functionalities of the system and their interactions. The intelligent pieces, the managers, are able to communicate to other managers facilitating a common management approach. A higher intelligent entity (user, GUIs, debugging tools, CCRM applications, etc.) serves as centralized interaction gate towards the whole framework, the CMD MAN Daemon. This interaction is currently supported through text-only commands, although, some standard API interfaces could be implemented (Java, Python, C++, etc.) to enable the development of GUIs or debugging tools.
