Difference between revisions of "WISE-Agent"

From ESS-WIKI
Jump to: navigation, search
Line 136: Line 136:
 
               All libraries required in modules.
 
               All libraries required in modules.
  
 
+
[[File:AgentTester.png|760x600px|Architecture of AgentTester]]
  
 
 
 
 

Revision as of 06:43, 3 October 2016

Introduction

WISE Agnet – a software development framework to communicate between device and RMM Server.
Advantech provides a software development framework to communicate and exchange information between a device and RMM Server, called a WISE Agent framework.
The WISE Agent framework provides a rich set of user-friendly, intelligent and integrated interfaces, which speeds development, enhances security and makes agent application easier and simpler to communicate with RMM Server.
The framework has three benefits:

  • Standardization - The communication protocol is based on the MQTT protocol to communicate and exchange data with WISE-PaaS/RMM Server. The IoT sensor data report format is following the IPSO Spec. in JSON format.
  • Portability - Whole framework is written in C language and follow the ANSI C Standard, that C compilers are available for most systems and are often the first compiler provided for a new system.
  • Scalability - The WISE Agent Framework is functional partitioning into discrete scalable, reusable modules, and plug & playable.

Architecture

In WISE Agent Framework, it includes two parts: WISE Agent and Handlers.

  • In Provisioning & Communication block, There are defined two structures:
  1. Platform Profiler structure describe the target platform, include: OS version, SN, Device Name, MAC address, …
  2. Configuration structure describe how to connect to RMM server, such as Server IP, Listen Port, TLS/SSL setting, …

 And the Agent Client is the main library of WISE Agent to communicate with RMM Server, based on MQTT protocol.


  • In Core Management block,
  1. The Core Manager integrates and manages the WISE Agent resources and keeps them alive.
  2. The Handler Loader is responsible to load and manage the handlers, that indicated in module_config.xml file.
  3. The RMM Command is responsible to handle the commands that control the Agent, such as: Agent Rename or Agent Update.

 

  • The Handlers part includes the handlers we implement for RMM Agent, such as SUSI Control, Power On/Off. And any other custom handlers that implemented follow our Handler APIs.

WISEAgent SW Architecture

Handlers

In RMM Agent we provide several handlers and can be classified in three different categories:

  • Monitoring Handlers - sensor data monitoring and control.
Such as: Hard-disk Monitor, SUSI Control, Network Monitor, Process Monitor, IoT Gateway and Modbus.
  • Control Handlers - remote control target device.
Such as: Power On/Off, Remote KVM, Screenshot, Terminal, Protection and Recovery.
  • Agent Improvement Handlers - to increase the agent reliability or functionality.
Such as: Server Redundancy.

RTENOTITLE

WISE-Agent Sample Handler

  • Modbus Handler - version 2.0 only support Modbus-TCP, Modbus-RTU supported since version 3.0.

Modbus handler is one of handlers in WISE Agent framework and is used to collect devices’ data based on Modbus TCP protocol.
The library used in Modbus handler is libmodbus, which is a 3rd party free library to send/receive data according to the Modbus protocol.
This library is written in C and supports RTU (serial) and TCP (Ethernet) communication. The license of libmodbus is LGPL v2.1v.

The flow of WISE Agent communicating with a device based on Modbus by Modbus handler is described as follows.
The WISE Agent uses the Modbus handler as the interface to handle all the communication with the device based on Modbus protocol.

  • Steps of Modbus Handler:
    • Step1 Modbus handler reads in INI file and is ready to set up connection with device according to the configuration in the INI file.
    • Step2 Modbus handler establishes a Modbus connection
    • Step3 WISE Agent communicates with the device.
    • Step4 If you no more need the communication, WISE Agent can disconnect with the device.

Steps of Modbus handler



  • GPS Handler - version 1.0 only support NMEA 0183 format with serial port.

GPS Handler is used to parse the GPS stream in NMEA 0183 format and report current position to server continuously.

The report information include: Serial Port Name, Mode, Timestamp, Latitude, Longitude and Altitude.

Mode 2 means the GPS device only support two-dimensional information without Altitude.

Mode 3 means the GPS support three-dimensional information with Altitude.

RTENOTITLE

The GPS Handler config file is only need to define the serial port attribute, include: Serial Port and Baud Rate.

The default GPSHandler.ini is read stream from com 1, and the baud rate is 9200.

[Platform]
SerialPortNum=1
Baud=9200


  • RFID Handler - version 1.0 only support FAVITE low level command protocol.

RFID Handler is interacted with FAVITE RFID Reader with low level command protocol through serial port.

The report information include: Serial Port, Baud Rate, Parity Mode, Stop Bits, Byte Size, Manufacturer Name, Product Name, Serial Number and EPC Code.

RTENOTITLE

The RFID Handler config file is only need to define the serial port attribute, include: Serial Port and Baud Rate.

The default RFIDHandler.ini define the serial port with read stream form com1, baud rate is 115200, stop bits is 1, parity mode is none and byte size is 8.

And enable the debounce with set the toggle target to disable and query command inventory session flag to 1.

[Platform]
SerialPortNum=1
Baud=115200
StopBits=1
Parity=0
ByteSize=8
# Toggle 0:disable, 1:enable.
# Inventory Session 0:s0, 1:s1, 2:s2, 3:s3
# Set toggle:0 with Session:0~4 in different trigger rule to support debounce.
Toggle=0
Session=1

WISE-Agent Verification Tool

AgentTester – a software tool for testing all sorts of functions and modules of the Agent.


Architecture

The architecture of AgentTester is described as follows. The agent includes three different layers: Main, Module and Library.

 

  • Main Layer

               The main executable function to load all the modules required to test functions of an agent.

  • Module Layer:

               All modules used to test functions of an agent.

  • Library Layer:

               All libraries required in modules.

Architecture of AgentTester

 

Configuration

AgentTester takes an INI file (CheckerSetting.ini) as its configuration to know which modules are required to test an agent according to a user’s requirements. User can modify INI file to load or unload modules for meeting his/her wanted test conditions.

 

  •  Modules Section

               This section is used to define how many and which modules required to load. And the required operation time for the module.

  • Server Section

               This section describes the server setting, which must be as same as agent_config.xml with your test target.

  • Reconnect_Server Section

                The section for ServerRedCK to test server redundancy. The setting consists of the configuration of a slave server to reconnect. (only support the same server as [Server])

  • Device Section

                The section defines DeviceID.

  • Topics Section

                The section describes a topic to subscribe. (only one topic allowed, use '+' to receive messages as many as possible)

  • HandlerList Section

                The section describes a list to test handler list.

  • Capability Section

                The section describes a list of handlers has to go through capability test.

  • Report-Upload-Get Section

                The section describes a list of handlers has to go through report, upload and get test.

  • Set Section

                The section describes a list of handlers has to go through set test.

Modules

This section introduces all modules called Checkers in AgentTest used to test functions of an agent.

 

  • ConnetionCK

                The module is used to check connection functions of an agent such as reconnect function.

  • GHandlerCapRepCk

                The module checks general handler’s functions including capability and reported data.

  • HandlerCapGetSetUploadCK

                The Checker tests handler’s functions including capability, get, set and upload.

  • HandlerLSCK

                The Checker checks handler list to know what handler an agent loads.

  • ServerRedCK

                The Checker tests ServerRedundancyHandler’s functions including reconnect function and others.

  • AServiceCK

                The Checker checks agent service’s status and functions.

  • WatchDogCK

                The Checker checks WatchDog’s status and functions such as restarting a killed agent.

  • IoTGWCK

                The Checker checks IoTGWHandler’s functions and the sensor hubs under the gateway.

  • AProcessCK

                The Checker continuously checks agent process’s status.


All the modules above can be loaded or unloaded according to a user’s requirements or test conditions. By setting a suitable ini configuration, the test result could be simple and easy-to-read, no redundancy report would show.

Document