The Arrowhead Framework (AF) is a framework that provides interoperability between services in a Service Oriented Architectue (SOA) systems. The actual scope and its definition are not easy to understand at first and its documentation does not always help, so the following paragraph will try explain the basics of the AF.
The AF is a set of interfaces, rules and documentation system that allow devices to provide and consume services. The AF defines types in an abstract way for Services, Cloud, System and others concepts.
The AF also stablish that there should be at least 3 main systems (also called core systems) in a local cloud: ServiceRegistry system (allows to register, unregister and query for services), Orchestrator system (allows to find provided services that were designated to devices to consume) and the Authorization System (manages all authorization needed between devices and services). These systems, together with others that aren't mandatory, provide a set of defined services, which of course are defined using the interfaces and types of the AF. The documentation of each system can be found in the folder for it in the github repository. It's important to nothe at this point that all services defined for the core systems are implementation-independent, but HTTP/JSON is the first and the de-facto official implementation, but the services could use other communication and modeling protocols.
The service that your system will produce or consume is not defined in the AF, but how you should document it, it is.
The basic sequence for having a service being produced and consumed in the AF is the following:
As seen before, the service interface between the consumer and provider is not fixed and the AF has nothing to do with it. The AF provides the support to register services, and look for them.
The developed 4DIAC's Arrowhead library provides the FBs and AF types to communicate to the official Arrowhead Framework using HTTP/JSON.
The first thing that's needed is to have a version of 4diac FORTE with the Arrowhead Module enabled. For that, you'll need to compile your own 4diac FORTE. To do that, follow these steps and in CMake set the variable FORTE_MODULE_Arrowhead and FORTE_COM_HTTP to TRUE.
After 4diac FORTE compiles, you'll be ready to use the FBs library in 4diac IDE.
The 4diac IDE is where the library of Function Blocks were defined, and it was done in three levels. In the lowest level, helper Function Blocks allow the user to create the Arrowhead Framework types using standard types from IEC 61499. The following figure shows the Function Block to create an Arrowhead Cloud type, which can later be connected to the upper levels.
On the second level, the actual Arrowhead services were implemented. These Function Blocks offer an adapter following the IEC 61499 standard, in order to decouple the abstract definition of services from the actual implementation. As an example, the following figure shows the Function Block to register and unregister a service in the Service Registry. The data inputs are a Service Registry Entry type (protocol independent) and the endpoint to connect to. The “registerService” adapter on the below right side, offers a plug to the actual implementation of the communication, passing all needed data.
The socket for this adapter is given by each implementation. The next figure shows the Function Block that implements the actual HTTP communication to the Service Registry. Its only input is the socket adapter, the counter part of the plug adapter from the previous figure. By connecting them, the information is passed to this Function Block that handles the communication.
This decoupled architecture allows to quickly implement another type of communication. For example, if the Service Registry offers an OPC UA interface, only the Function Block in the last figure must be re-implemented with the specifics of OPC UA.
On the top most level, sub-applications were implemented in order to facilitate the user using the library. For example, for registering a service, instead of building from the lowest level, which requires many Function Blocks and connections, an encapsulated sub-application is provided that offers all parameters for it. The following figure shows the sub-application with all parameters to register and unregister a service.
The following gives informatoin about the purposse of all FBs and SubApps in the library. The parameters of each one of them is documented in the FBs and SubApps itself.
The ones marked in bold are the top level, and usually, the only ones that you need in order to quickly use the library.
Go back to Protocols index:
If you want to go back to the Start Here page, we leave you here a fast access
Or Go to top