LLMCMSS.10 - LLM CMS reference architecture

In order to refer to functional entities in the CMS specification, a reference architecture of the LLM system is assumed. The LLM CMS specification will refer to parts of this reference architecture when it comes to specify attibutes or behaviour or interfaces between entities.

The elements in the yellow shaded area in the picture are objects of the LLM CMS specification. All other objects are used as LLM CMS have interfaces to them or their interfaces are used by LLM CMS too.

LLMCMSS.10.02 - Concepts in the reference architecture

This reference architecture has been chosen to reflect the most probable functional component landscape the LLM system (the LLM system is assumed to be the technical system providing the LLM service) will be composed of.

LLMCMSS.10.02.01 - Seperated and not separated components: LUI and RUI

There are components that look similar but have completely seperate behaviour and implementation. Examples of such component "pairs" are the  LUI and RUI components.

Each component has a LUI - Local User interface - and a RUI - Remote User Interface. The LUI is the user interface for the local user and performs user-centric tasks. The RUI is the user interface for the remote access user and the administrator and performs user-centric tasks as well as administrative, management, configuration and troubleshooting tasks. To a certain extent (detailed with each component having LUI and RUI) the LUI is a (rather small and simple) subset of the RUI.

The RUI is an built-in functionality of each component and as of LLM system architecture V 1.0 an HTML-based web user interface. It provides all user interaction the respective component is capable of. As a result, the RUI is tightly bound the the component itself and uses only loose coupling to other RUIs and therefore assumed as being part of the component itself.

The LUI is more simply and user-centered. All LUIs of a LLM-system are much more tightly and seamlessly integrated to provide maximum usability and comfort. Therefore, the LUIs share a lot of common functionality and are more tightly interwoven than the RUIs. Moreover, the LUIs are in some places "wrappers" around the "original" user interface of a component. As a result, the LUI of a component makes sense to be separated from the component.

LLMCMSS.10.02.02 - Integration of already existing components

1. Moreover, already existing components, as CTC, ILC and (to become) PTC, shall be able to take part in this architecture as-is.
2. However, ILC, CTC and PTC are here referred to as placeholders for any ILC, CTC or PTC that fulfils the behaviour required for taking part in a functional LLM system. How this can be accomplished is detailed below in the respective section(s) covering these components.
3. Special attention shall be given to re-usability by well-chosen implementation of integration components, detailed especially for CTC and PTC in different variants set forth in LLMCMSS.07.02.01.02.

LLMCMSS.10.02.03 - LUI - Local User Interface and LLF - Local user interface framework

There are a number of LUI - Local User Interface - Components in the LLM reference architecture. The LUI is a user interface intended for the local, not technically skilled and, most probably, physically challenged, user.

For the purpose of the LLM CMS the assumption will be made that the eHome LUI already has proven to be able to meet the requirements for a LLM LUI. Furthermore, it is already existing and can be easily adapted to the functions required in LLM LUI.

Therefore, the eHome LUI software component and platform shall be adopted for all LUI components in the LLM architecture. The framework extracted from the eHome software package shall be called LLF - LLM LUI framework - for the sake of brevity and identification.

The LLF is a windows application running on a specific set of touch-enabled net-top intel x86 hardware and operating system platforms. It is specified in the LLF specificationpart of this specification.

LLMCMSS.10.03 - Components of the reference architecture

The reference architecture is divided up into components each fulfilling a specific functionality.

LLMCMSS.10.03.01 - 1.1.1 - The LLM-LUI

1. The LLM -LUI is the central local user interface to one LLM-system. It is the central entry point to all components of an LLM instance. The LLM-LUI shall allow access to:
   1. ILC-LUI - The local user interface of the independent living component
   2. CTC-LUI - the user interface of the cognitive training component
   3. PTC-LUI - the user interface of the physical training component, see also variants considered in LLMCMSS.07.02.01.02
   4. CMS-LUI - the administration user interface for the whole LLM system
2. The LLM-LUI shall also present the single point of authentication for a user. After login into the LLM-LUI, all user credentials shall be carried on to the connected subsystems and their LUIs. A user shall only need to login once and then be known to all subsystems with all their data and access rights.
3. The process of making one LUI visible, most probably implemented by bringing its window to the front of the display screen, is named switching.
4. The LLM-LUI shall switch between the respective user interfaces as seamless as possible (depending on the ways viable in integrating the user interfaces of already existing components).
5. Switching shall not only be initiated by the human user, but also by a subsystem needing attention shall be able to bring its LUI to the front and attention of the user.
6. The LLM-LUI shall be implemented using the LLF, specified in LLMCMSS.05, in order to be integrated in one single LLF-instance with all other LUI-components of the LLM-system.

LLMCMSS.10.03.02 - 1.2.1 - The ILC-LUI

1. The ILC-LUI is the user interface of the independent living component. It is integrated into the LLM-LUI.
2. As of the time of releasing this specification, the only available ILC implementation used in LLM is eHome . It is assumed that the LLM-LUI will use the same base technical implementation as the eHome-LUI. Therefore, integration shall be as tight as possible and the ILC-integration into LLM-LUI shall serve as the blueprint of an "Integrated Application" in terms of LUI-interaction.
3. The ILC-LUI shall be implemented using the LLF, specified in LLMCMSS.05, in order to be integrated in one single LLF-instance with all other LUI-components of the LLM-system.

LLMCMSS.10.03.03 - 1.2.3 - The CTC-wrapper-LUI

1. The CTC-LUI is a wrapper component around the real user interface of the cognitive training component. It is assumed to be integrated into the LLM-LUI.
2. The Integration of CTC is not part of the CMS development. However, the following assumptions are made to enable CMS development:
   1. CTC is running on the local terminal platform and is a native windows application.
   2. CTC can be started like any other windows application, the PID can be got from the invocation system call.
   3. The completion of CTC can be monitored like any other windows application by watching the PID until disappearance.
   4. Before start, there may be a preparation sequence setting the environment by querying the LLM-DB.
   5. After completion there may be a result gathering sequence writing tot he LLM-DB results store.
   6. All the CTC preparation, start, completion and result gathering shall be encapsulated in a DLL function call "CTC-invocation".
   7. The DLL containing the CTC-invocation shall comply to the LLF function API standard and shall be delivered by the CTC-integration development team (at AUTH).
   8. Whether the CTC-invocation function is synchronous or asynchronous shall be agreed bilaterally between the CTC integration development team (at AUTH) and the LLF development team (at ISTU). Per default, CTC supervision and error handling (timeout, program hangup, etc.) shall be handled within the CTC invocation function call without emburdening the LLF with such supervisory tasks.
3. The CTC-LUI-integration shall be implemented using the LLF, specified in LLMCMSS.05, in order to be integrated in one single LLF-instance with all other LUI-components of the LLM-system.

LLMCMSS.10.03.04 - 1.2.2 - The CMS-LUI

1. The CMS-LUI is the user interface of LLM-CMS, the Central Management System. The CMS-LUI covers a subset of all possible administrative activity of the CMS, namely the part important for the local user, like viewing statistics, schedules and results, changing password or other user parameters. More detailed administrative and management activties are handled by the CMS-RUI, specified in LLMCMSS.04.05, built into the CMS, specified in LLMCMSS.04.
2. The CMS-LUI shall be implemented using the LLF, specified in LLMCMSS.05, in order to be integrated in one single LLF-instance with all other LUI-components of the LLM-system.

LLMCMSS.10.03.05 - 1.3.2 - The CMS

The CMS is a web-service providing the "business logic" of the management functionality. It offers an Web-Service-API for a number of functional groups:

• session management (for LUIs and other up-stream components
• user data administration
• general configuration management
• workflow processing
• notification processing
• schedule administration and handling

There can be any number of CMS instances per LLM-DB instance but one CMS instance only has access to one LLM-DB instance.

LLMCMSS.10.03.06 - 1.5.5 - The LLM-Database / LLM-DB

The LLM-DB is the central data storage component of one LLM-system. It holds all persistent data centrally for one LLM-system. All other components are required to refer to the LLM-DB to store and retrieve persistent data.

The LLM-DB exposes the LLM-Web-Service-Interface built on SOAP for all data manipulation and retrieval.

LLMCMSS.10.03.07 - 1.4.5 - The LRF - LLM reporting and feedback functionality

The LRF generates feedback and reports for all types of users when triggered by another application.

Any application activity, when it has data to be brought to the attention of users, can trigger a report (or feedback, when it comes to informing the user about the performance of a training session) to be generated. This triggering is performed by invoking a trigger method on the LRFs web API. The LRF then produces the appropriate representation of the data requested.

The data the LRF works on is taken from the LLM-DB. The result, any type of appropriate information, usually (but not limited to) human-readable and displayable on a LUI or RUI, is also deposited in the LLM-DB. Input and output of the reporting/feedback process are held in the same area of the LLM-DBs storage, in order to make the result of one report available as input for another report.

LLMCMSS.10.03.08 - 1.4.4 - The PTC -  Physical training component

1. All specific PTC-Integration development shall be done by the PTC-integration development team (at AUTH). PTC is assumed to have no LLM-LUI-integratable user and operational interface. The complete interaction between CMS and PTC is done via configuration data and result data in the LLM-DB.
2. There are 2 Exceptions:
   1. There shall be a relation structure in the LLM-DB between local terminal and training program and the PTC-device. The PTC device may have an entry in its configuration structure about a control Web-API. If this entry is present and the control web-API supports emergency-freezing (powering down, etc.) of the device, the "Alarm Setting" Workflow LLMCMSS.06.02.03 shall use this functionality (variant A) to shut down the PTC device in Action 21.
   2. The PTC shall notify the CMS about the termination of a training session via the CMS Event Web-API. If the PTC is not capable of this notification (needs to be detectable by the CMS by looking up the PTC device configuration properties), the CMS will change Workflow LLMCMSS.06.02.02 - "senior performing training session" to not display "PTC Session active" but return to senior main menu or to place a button on the PTC active screen of rthe user to inform the LLM system that the PTC training session is complete.

LLMCMSS.10.03.09 - The LLF instance

The LLF-instance is the running program on the local  terminal platform handling all LUI interactions and displaying all the screens.

The LLF-instance is the program that is started either autoimatically of by the user or an administrator and then occupies the complete local terminal screen and is the only component to interact with the user.

The LLF-instance handles 2 types of events:

• user actions by pressing on-screen buttons or entering texts onscreen.
• events "injected" via a web-service interface.

These events can leat to display updates, change of screens or more complex activcity involving interaction with application service web-API (such as CMS or LRF)

LLMCMSS.10.03.10 EXTAUTH - The optional external authenticator

EXTAUTH is an optional software component running hiddedn in parallel with the local terminal LLF instance. Its purpose is to monitor for instance a smart card reader and to detect the presence of a smart card authentication token. It then takes the user credentials (code, ID, username/password or whatever is provided by the card and issues an event to the LLF-instance's web-service API whcih has the same effect like a user logging in.

Optionally, the removal of the smart card can lead to logout or terminal locking, depending on future requirements, but this is NOT part of the current LLM service implementation scope.