# A Multi-Usable Cloud Service Platform: A Case Study on Improved Development Face and Efficiency
## 4 A Multi-Usable Cloud Service Platform and the Case Study's Three Contexts
### Multi-Usable Cloud Service Platform--Architecture  
The multi-usable cloud service platform from the company was initially developed using legacy technology and techniques. This was not deemed as efficient and scalable, and as the Arrowhead Framework and its components were made available during the Arrowhead project's progression (2014-2017)--the company re-engineered the complete solution and based it upon the Arrowhead Framework components as well as its proposed development processes and other related frameworks.  
In brief, the Arrowhead Framework comprises the following main systems, sub-systems, procedures and methods [8; 23]:  
* **Mandatory core systems--**service registry, authorization, orchestration
* **Automation support systems--**plant description, configuration, system registry, device registry, event handler, quality of service manager, historian, gatekeeper, historian to historian secure data path, translation
* **Application systems--**application services
* **Deployment procedure--**secure bootstrapping of devices and systems into a local cloud, creation of Arrowhead Framework compliant systems, interfacing legacy systems, verification of compliance  
Figure 1 outlines the new architecture, based on the Arrowhead Framework [23], for the company's cloud service platform. The architecture comprises the mandatory core systems  
and services, including an authorization system (for users and services, etc.), a service registry (where services can be registered and looked up), and an orchestration system (in order to maintain system connections), and an application systems and services part. The latter contains the actual business logic and provisioning, which differ for each context. The SOA principle is based on the foundation of the three 'L's, Lookup (discover/set presence), Loosely coupled (autonomy's and distributed components) and Late binding (dynamic system of system compositions) together with strictly defined service contracts and architectural methods.  
In further detail, the function calls and parameters used in Figure 1 are briefly outlined (for additional details see [8; 23]). Input parameters are in normal text and output parameters in bold text:  
* Authorisation (Service Discovery, **Authorisation Management, Authorisation Control**)--provides authorization and fine grained access rules to specific resources as well as configuration of access tickets in combination with use of authentication mechanisms such as, for instance, certificates and certificates handling
* Service Registry (**Service Discovery**)--provides service registry functionality based on DNS and DNS-SD standards. The architecture and solution handle self-registering services, which state their availability within the network. Consumers of specific information knows where they can find and use it. Producers notify their awareness. This handles the SOA-principles called lookup and late binding
* Orchestration (_ahfc-servprod types, Authorisation Control, Service Discovery, Orchestration Push, **Orchestration Store, Orchestration Capability, Orchestration Management**)--provides service consuming systems with consumption patterns as well as end-point information of the produced services that are to be consumed. The function provides the possibility to combine a system-of-system collaboration that fulfill the current need for a specific situation. Further, this handles the SOA-principles called late binding and loosely coupled.  
Figure 1: Outline of general architecture of Adage AB’s multi-usable cloud service platform.