logo_header
  • Topics
  • Research & Analysis
  • Features & Opinion
  • Webinars & Podcasts
  • Videos
  • Event videos

Choosing a closed loop pattern and logical architecture

To make control systems reliable and dependable, automation requires intelligent feedback patterns to be introduced to effectively address changing conditions while reducing low-level human involvement.

17 Mar 2021
Choosing a closed loop pattern and logical architecture

Choosing a closed loop pattern and logical architecture

This article was written by members of TM Forum’s Closed-loop Anomaly Detection and Resolution Automation project. Authors include: Aaron Boasman-Patel, Vice President – AI & Customer Experience, TM Forum; Emmanuel Otchere, Chief Architect, Huawei; Mathews Thomas, Executive IT Architect, IBM; Satishkumar Sadagopan, Associate Partner / Executive Architect, IBM; Utpal Mangla, VP & Senior Partner, IBM; Vikrant Bhargava, Deputy General Manager, Bharti Airtel. Find the first in this three-part series here. Please also register for the webinar – Enabling the networks & services of tomorrow using AI closed loop automationfor further insights.

Closed loop patterns evaluation

Industry, from the time of steam/water powered mechanization to mass production with electricity and information communication technology (ICT) based systems, use control systems in automation. In a knowledge-based environment, service providers must bridge physical and digital operations together in order to manage services and experience at scale and speed. Control systems such as the ancient Ktesibios's water clock in Alexandria, Egypt – since invention around the third century BCE – have been instrumental to manage, command, direct or regulate the behavior of “systems” for deterministic outcomes. These systems heavily depended on human intervention. To make control systems reliable and dependable, and thus release autonomous behavior in real-world conditions, automation requires intelligent feedback patterns to be introduced in order to effectively address changing conditions, while reducing low-level human involvement.

graphic

There are several feedback patterns, which help to effectively engage and govern real world circumstances with their changing conditions. A good feedback pattern provides a framework that can effectively embed the right part of the output of a control system, at the right stage, back into the system using an intelligent decision planning process. Some patterns provide basic feedback analysis, while others have evolved based on the complex nature of decision making. The choice of a system for any use case may differ, but there is general consensus that feedback systems need to integrate some forms of intelligence to address the modern-day complexity.

Choosing the Observe-Orient-Decide-Act (OODA) closed loop pattern

To identify a generic pattern that can support the complexity of managing anomaly detection and resolution across disparate and integrated systems (expert systems and domains), the OODA Closed Loop pattern was selected. Others like Monitor Analyze Plan Execute (MAPE), Foundation Observation Comparison Action Learn, rEason (FOCALE), Plan-Do-Check-Act (PDCA) etc. were analyzed along with OODA by asking some relevant questions that included: Based on the analysis, merits and scope of various closed loop patterns, the Closed Loop Anomaly Detection and Resolution Automation (CLADRA) project identified OODA as an exhaustive and yet generalist pattern to enable adapt to different anomaly detection and resolution use cases. ETSI GANA, FOCALE and CASCADEs can be used too as they are extensions of OODA. However, OODA in its purest form provides a generic framework to model the common entities.

  • The organization of the framework – Is it for purely for technical use, or operational, business, etc.?
  • The pattern design pivot - Is it one node centered, a system of nodes focused etc.?
  • How “dynamic” is the pattern? Is the pattern able to address static information paths? Dynamic information paths? Is it adaptive? Can it support recursive feedbacks?
  • Is the pattern able to support self-organization?
  • Does the pattern include context awareness of the environment?
  • How well is the pattern documented for reference and adaptation?
By leveraging AI, the OODA Closed Loop pattern presents exhaustive feedback loops that address the different stages of decision cycle with “fast loops” and “slow loops” reflecting the different decision points that represent intelligently managing the automation of anomaly detection and resolution.

CLA Architecture alignment with OODA

The CLADRA reference architecture provides a validated framework that is vendor or product agnostic. It can be used to automate anomaly detection and resolution through standard functions, components and interfaces. For eTOM-based service and resource management to utilize closed loop automation, it is very important to identify and develop logical, physical and operational architectures based on practical designs, implementation and operations experience.

In our effort, we leveraged the best practices contribution from CSPs, network equipment vendors, independent software vendors, and consulting & systems integrators to rationalize the components required for CLA in the service and resource domains of eTOM. It also highlights the layers, integration reference points and general specifications that address the ambitions of CSPs seeking solutions, and solution providers looking for standardized language of requirements to work together using a set of well-defined business and technical objects.

As reference architectures, it is not compulsory to implement the full stack of functionalities, components or interfaces. However, it is important to consider an end-to-end approach to design and implement closed loop architecture for anomaly detection and resolution knowing the target architecture. This is the added value the report offers. By starting with simple closed loop implementations, CSPs, vendors, consulting and system integrators etc., can better frame a comprehensive, pragmatic roadmap for fully automating, and effectively managing the lifecycle of CLADRA systems.

Logical architecture

Referring to the figure below, four key functional layers for closed-loop anomaly detection and resolution have been identified: Data collection, data composition, decision execution and process execution. The logical architecture also supports a number of cross-cutting capabilities (including security and automation) that need to be enabled in every layer and governed consistently across all layers. This allows for a loosely coupled architecture, with the facility to implement the functional modules with the best of breed components or custom components to best suit each of the components.

Graphic
  • The data collection layer maps to the “Observe” stage of OODA, and connects and collects data from resources and services. This includes data from compute, storage, network, applications, interfaces etc.
  • The data composition layer maps to the “Orient” stage of OODA and builds information across data sources through analysis, dissemination and reflection. This is where data is processed, cleansed, normalized and modeled.
  • The decision execution layer maps to the “Decide” stage of OODA where the AI/machine learning (ML) models are trained and executed. Based on the outcome form the AI/ML modes, appropriate decisions are made on the best resolution/action.
  • The process execution layer maps to the “Action” stage of OODA and models and executes the processes and actions determined by the “Decide” layer, through process orchestration, human-related workflows, robotic process automation etc.
  • The security layer runs across all the above layers and secures the solution from various aspects of infiltration and vulnerability, such as, user security, data security, application & infrastructure security

Taking action

As a use case led project, members adopt a rigorous review and validation of the architecture to enable practical industry best practices and standards. By using the OODA feedback framework, we intend to identify relevant data models, APIs and automation standards that will be used and improved by TM Forum member organizations. Feedback received from the membership will be used in subsequent iterations of this work to further develop and improve the architecture, integration into ODA and realization of standard automation objects. Some of the key items for future consideration are:

  1. Mapping to ODA
  2. Development of assets, like APIs and data models (as extensions to SID)
We invite the reader to join our current study on Closed Loop Automation; further details can be found here.