Afgeronde rechthoek: Top of book Afgeronde rechthoek: Managers track Afgeronde rechthoek: Technical track Afgeronde rechthoek: Previous page Afgeronde rechthoek: Home
 

 

 

 

 


System integration

Configuring modular systems

There are four types of modular systems.

·        Systems that have a preplanned configuration

·        Systems that can be upgraded during a stop of the system

·        Systems that can be upgraded during runtime

·        Systems that can be upgraded during a stop of the system and during runtime

‘Upgrading’ means adding new modules, or it means replacing existing modules with newer versions or with modules from a derived class. A preplanned configuration is not a fixed configuration. The configuration can change dynamically according to a plan.

The system may make use of an existing infrastructure that supports modules. However, it is also possible that during system configuration a tailored infrastructure is added to the set of selected and planned modules. The infrastructure can also be constructed from modules.

Specifying a modular system means specifying the modules that will be used in its preplanned configuration and specifying space for modules that may be used in a later phase. It also means specifying the connection scheme at the first realization and the schedule of the tasks that the system must accomplish. Each task schedule is accompanied by a required connection scheme. Apart from this initial change of connections, the tasks may alter the original connections. Altering the connections is often accompanied by the generation or the deletion of a dynamic instance of a module. The infrastructure takes care of the necessary corrections.

After the first realization of the system, it is possible that new packages are loaded into the system. This can be done statically during a stop of the system or dynamically during runtime. In both cases, the system must contain a package loader.

Designing modular systems

Designing modular systems starts with a specification of the requirements and the tasks that the system must fulfill. Then the market is searched for packages that contain modules, which can do at least a part of these tasks within the requirements that are set. If such a package cannot be found, then the architect may look for component suppliers that deliver packages that are constituted of separately published module classes. Module classes that are still missing must be designed and built locally. The architect orders a package with the wanted module classes that are available externally. He does this by first specifying the package. This might already enable him to create a prototype system. When the prototype proves useful, the system architect may order the binary format of the package. If module classes that are designed and built locally are fit for reuse, then they may be optimized for that purpose. This means, for example, that the new module should use popular interfaces and well-known types. In this way, a system integrator may become a component supplier or he may delegate this act to another institution.

A system configuration tool is capable of generating skeletons of modules from the information found in the public part of the module. This means that the configuration tool can construct testable prototypes from published specifications and local designs. As soon as the public part of the locally designed modules is specified, it will be possible to check the static configuration of the whole system. By gradually replacing the skeleton modules with active modules, a stepwise build of the target system can be achieved.

 

 

Afgeronde rechthoek: Top of page Afgeronde rechthoek: Next page