LLMCMSS.07 - LLM CMS Aspects: Configuration, Security, Modularity, Performance, Volumetrics

This section of LLMCMSS specifies all non-functional aspects of the LLMCMS subsystem:

• Modularity
• Implementation issues
• Deployment Architecture
• Configuration
• Security
• Performance
• Volumetrics
• Safety and Runtime Environment

LLMCMSS.07.00 - Document Control

LLMCMSS.07.02 - Aspects Details

LLMCMSS.07.02.01 - Modularity

LLMCMSS.07.02.01.01 - General terms and concepts

1. The LLM system shall consist of small installable entities called Packages. A package is the smallest installable entity.
2. A number of packages can be installed and work together in an Instance.
3. One or more Instances are created on one Node; a Node is one hardware box (1 PC, 1 server) or one partition in a multi-partition platform or one virtual box.

LLMCMSS.07.02.01.02 - modularity for reusability - special example: PTC and CTC integration

In an environment with so many variable parameters when it comes to system and device configurations as well as use cases and work flows, special attention shall be laid on building system components that can be re-used in other similar places.

To illustrate this requirement and underlying concept, one example which may well become reality shall be worked out here:

The common concepts in the integration of different sorts of PTC and CTC devices and software:

• As of LLMSYS V 1, the CTC is a software running on the local terminal and needing to be integrated into the display management done by the LLF.
• The PTC, on the other hand is assumed to be a "headless" device software with no own user interface. Therefore, the LLM system design uses a "dummy" activity display using a "process active screen" to show the approximate status of the PTC training session to the user.
• This results in the CTC integration and PTC integration being "blueprints" for two types of external systems being integrated into the LLM system.
• If now, what seems possible, the PTC gets its own user interface software, most probably running on the local terminal too, no further development should be necessary except for configuring the PTC integration , the respective screens and the PTC-related workflows and evtent processing, because the same model now necessary for the PTC integration has already been developed for the local terminsl based CTC integration

The above scenario shall be kept in mind in system design to make such a re-use of components feasible. The detailed system design shall be tested specifically for such use cases.

LLMCMSS.07.02.02 - Implementation Issues

1. Implementation shall be broken down in modular work packages as devised in Modularity and Deployment Archictecture subsections.
2. Implementation shall follow a rapid develop-test-refine iterative cycle in order to achieve early experiences with structures, user interface and configurability.
3. As of the current modularity structure and project status,there are the following modules to be developed in the whole LLM-system:
   Note: italic bold printed items are considered part of the LLM CMS activities
   Note: to the right of each item, responsible teams are noted: AUTH, ISTU, CEIT
   
   1. LLF - ISTU
   2. LLM-DB - AUTH
   3. CTC integration - AUTH
   4. CTC LUI integration - ISTU
   5. PTC integration - AUTH
   6. ILC integration - CEIT
   7. RUI Framework + Application Server - CEIT
   8. LLM-LUI screens - ISTU
   9. CMS-LUI screens - ISTU
   10. Workflow LUI screens - ISTU
   11. Flow specific CMS service code - CEIT
   12. Specific RUI object editors - CEIT
   13. LRF - CEIT
   14. LRF plugins with specific training result processing algorithm code - AUTH with domain experts
   15. non-editor CMS RUI code - CEIT
   16. generic CMS RUI DB-object editor - CEIT
   17. DB local replication - AUTH
   18. DB global replication (if different from local) - AUTH
   19. LUI and LRF localization concept - ISTU
   20. LUI und LRF localization and local texts - local project partners
4. As of the current modularity structure, the impolementation sequence could be as follows:
   1. first iteration: LLF development, LLM-DB development, in parallel with CTC integration and PTC integration, basic RUI functions (AppServer)
   2. second iteration: Version 1 screens and workflows, screen/flow-specific code libraries, specific object-editors, LRF development, DB local replication
   3. third iteration: LRF algorithms, RUI completion (all modules), generic DB-object-editor, DB global replication, RUI consolidation per-box

LLMCMSS.07.02.03 - Deployment Architecture

1. Deployment of LLM shall be on a combination of up to 3 node-types:
   1. local terminal node
   2. local/regional server node
   3. local/regional/global database node
2. Assignment of the functional modules to the node types shall be as shown in the "System Configuration" picture below:

LLMCMSS.07.02.04 - Configuration

This subsection deals with the way the LLM-System shall be configured reliably and efficiently.

1. For each LLM system Instance, there shall be a central instance of LLM-DB containing all node/package specific configuration. The address of the Web-Service providing the LLM-DB interface may be configured in an instance-wide configuration file or Web-Application-Serer configuration data set. It also can be held by an web service discovery repository. In this case it has to be determined how the repository is found in the network and where the repository is installed an running.
2. All configuration data has to be held in the LLM-DB instance associated with the respective local terminal instance or server instance.

LLMCMSS.07.02.05 - Security

1. All accesses to LLM-system components must be protected by LLM-managed credentials
2. Platform hardening measures shall be applied to prevent circumvention of LLM-system internal security.
3. No LLM-system component shall require system admin privileges for installation or execution
4. Network ports used for access to web-services shall be clearly documented in system documentation and firewall measures be taken to prevent access to any non-authorized port.

LLMCMSS.07.02.06 - Performance

1. All performance figures are to be taken with respect to the volumetrics limits. If volumetrics limits are exceeded, performance may not be guaranteed
2. All performance values and system function shall be guaranteed only when network performance is at least:
   1. The equivalent of 2Mbit/second between local terminal and server-node
   2. The equivalent of 2 Mbit/second between all client-nodes and the database-server node
3. Response times to all local-terminal (LUI) actions shall be less than 100ms average and must not exceed 300ms in worst cases
4. Response times to all remote-terminal (RUI) actions shall be less than 1 sec. average and must not exceed 3 seconds in worst case
5. In order to achieve reliability and performance, LLM-DB-instances shall be as close as possible to the local terminal and server nodes.
6. To meet database concentration and local distribution requirements alike, a database replication scheme shall be folowed:
   1. local database shall be replicated into a regional instance
   2. regional instances shall be replicated into a global instance
   3. change propagation, propagation latency and direction as well as data-mastership (e.g. local overwrites regional, ...) shall be flexibly configurable inside the DB itself.

LLMCMSS.07.02.07 - volumetrics

1. One local terminal shall support one user at a time under normal circumstances. To cater for headroom, one local terminal support all of the combinations below:
   
   1. 4 interactive user sessions (LLM-LUI, CTC) at a time or
   2. 2 interactive users (LLM-LUI, CTC) and services (CMS,LRF) and database (LLM-DB) or
   3. 3 interactive users (LLM-LUI, CTC) and services (CMS,LRF)
2. One site-local server shall support:
   1. 60 user sessions AND services for them (CMS,LRF) OR
   2. 30 user sessions AND services for them (CMS,LRF) AND database for them (LLM-DB) OR
   3. database for 240 user sessions
3. One regional database server shall support
   1. active database for 1200 users OR
   2. backup/replica database for 10000 users
4. One global database server shall support
   1. active database for 10000 users OR
   2. backup/replica database for 50000 users

LLMCMSS.07.02.08 - Safety and Runtime Environment

1. All software shall be able to run under a configurable operating system user account.
2. Neither for installation nor for execution administrator privileges shall be necessary. If there are admin provileges required for certain preparations, these actions shall be described in detail in the technicak documentation and be separately executable form the software installation and execution.
3. All installed and configured software components shall automatically start when the system platform is started and shall be orderly shut down at system shutdown
4. In case of components crashed due to fatal software errors, an automatic monitoring component shall restart the crashed components after collecting evidence about the possible cause and status of the crash