software development |
Copyright © Heinz Prantner 2007
created: December 13 2007
last updated: December 13 2007
Specify the generic software layout of a telecommunication system independent of the services provided or the services beeing used, indpendent of the technology and protocols involved and independent of the location in the network.
Telcommunication Systems on one hand are defined and designed by the technology and protocols involved, the services being provided or used and the location in the network. On the other hand there are several topics in common, independent of the influences listed above. This design model shall address the generic aspects of a telecommunication system.
Use this pattern when designing a system and
Platform
System Manager
The system may be distributed or a single platform system,
it consits of one or more platforms, connected devices,
external users and interfaces to other systems.
The system manager is responsible for the following tasks:
Platform Manager
A platform boundary can be a process, a board, or a application.
A platform is a subdivision of a system and builds the components
of a distributed system. In other words, a distributed system
consists of multiple platforms. Usually a platform is a single
process or a application. The platform manager is responsible
for the following tasks:
Data Manager
Telecommunication systems deal and interact with external
users, connected devices, interfaces to other systems, peer
systems and services, all of whitch come with their configuration
and state data. The data manager is useful to share these informations
between components within the system and to take care for persitent
storage. The data manager is responsibe for the follwing tasks:
Statistics Manager
Statistics are a very powerful instrument for bug tracking, load and stress testing, throughput and performance evaluation. Statistic measurements can be turnd on and off, may be pulled or pushed, need to be collected and presented in an appropriate manner and format.
Event Manager
Events inform the user about important state changes of the system, the devices, connections, services, peers. Events have a name, parameters and may have a priority.
Log Manager
Events and more detailed information on the system changes can be logged to a file or to a output stream.
Configuration Manager
The Configuration Manager, also known as Layer Manager, Stack Manager, is responsible to configure and setup the protocol stack components according to data given in persitent storage or on user command request. Bottom Up configuration of the protocol stack is preferrable.
Command Manager
The system may be operated via a console driven command language interface (CLI), or man machine interface (MMI), a graphical user interface (GUI), a remote management information base (MIB) with SNMP commands, a local binary application interface (API), a modem AT command interface, and the like. The Command Manager should provide for various interfaces and multiple users and process and distribute the commands within the system.
Connection Manager
The Connection Manager builds the abstraction layer to the various signalling and
data connections by hiding the specific interfaces to the lower layers and drivers
and providing a generic interface for connections to the users for
Protocol Stack Engine
Application
A distributed system may use the Platform layout for each participant with different build and run-time options and configurations, e.g. Active / Standby. So each platform may have all or a subset of the system components given in the model.
It is impossible to think of a telecommunication system without any data (configuration and volatile state information) and according data handling associated to it. It is possible though, to implement such a system without a dedicated data management. As a consequence, any new feature where data exchange between components is involved, the data handling has to be designed and negotiated from scratch with unforseeable problems at interfae alignment attached to it. A well defined data management allows for introduction of new features in a controlled and smooth manner. The same applies for other topics such as events, statistics, commands, log, etc.
Sample C++ code for Platform.h:
#include "system/system/SystemManager.h"
#include "system/platform/PlatformManager.h"
#include "system/configuration/ConfigurationManager.h"
#include "system/connection/ConnectionManager.h"
#include "system/event/EventManager.h"
#include "system/log/LogManager.h"
#include "system/data/DataManager.h"
#include "system/statistics/StatisticsManager.h"
#include "system/command/CommandManager.h"
class Platform
{
SystemManager *sysman;
PlatformManager *pfmman;
ConfigurationManager *cnfman;
ConnectionManager *conman;
EventManager *evtman;
LogManager *logman;
DataManager *datman;
StatisticsManager *staman;
CommandManager *cmdman;
public:
Platform();
~Platform();
void init();
bool run();
void shutdown();
};
Sample C++ code for Platform.cpp:
#include <iostream>
#include "Platform.h"
Platform::Platform()
{
std::cout << "Platform::++() " << '\n';
}
Platform::~Platform()
{
std::cout << "Platform::--() " << '\n';
delete sysman;
delete pfmman;
delete cnfman;
delete conman;
delete evtman;
delete logman;
delete datman;
delete staman;
delete cmdman;
}
void Platform::init()
{
std::cout << "Platform::init() " << '\n';
sysman = new SystemManager();
sysman->init();
pfmman = new PlatformManager();
pfmman->init();
cnfman = new ConfigurationManager();
cnfman->init();
conman = new ConnectionManager();
conman->init();
evtman = new EventManager();
evtman->init();
logman = new LogManager();
logman->init();
datman = new DataManager();
datman->init();
staman = new StatisticsManager();
staman->init();
cmdman = new CommandManager();
cmdman->init();
}
bool Platform::run()
{
std::cout << "Platform::run() " << '\n';
sysman->start();
pfmman->start();
cnfman->start();
conman->start();
evtman->start();
logman->start();
datman->start();
staman->start();
cmdman->start();
while (pfmman->run());
return false;
}
void Platform::shutdown()
{
std::cout << "Platform::shutdown() " << '\n';
sysman->shutdown();
pfmman->shutdown();
cnfman->shutdown();
conman->shutdown();
evtman->shutdown();
logman->shutdown();
datman->shutdown();
staman->shutdown();
cmdman->shutdown();
}
Define a protocol stack component architecture facade with protocol independent ports which fits into the generic telecommunication system layout.
Finding the right granularity in an abstraction is not easy to achive. If the granularity is to small then we are no longer generic, if the granularity is too big then the abstraction may be too vague. This facade pattern is refining the interface of a component processes primitives by breaking down the intreface into different generic categories.
end of document