EdgeApp Detailed Design Documentation

CalAmp Telematics EdgeApp (CTEA) Design Details

The purpose of EdgeApp is to provide third party developers the ability to add CalAmp and custom telematics application to the CTEC platform. An EdgeApp application is similar to any other CTEC application in architecture and is developed using the CTEC framework. The CTEC framework provides the standard OS constructs that is typically found in an RTOS like, threads, queues, semaphores, mutex’s, shared memory objects, etc. This framework is supported by multiple platforms, as shown below, but EdgeApp support is currently only available on Linux Applications. Future releases of EdgeCore will support additional RTOS platforms such as ThreadX.

1225

The intent of the EdgeCore Framework is to abstract EdgeCore and EdgeApp application from resident operating system allowing EdgeApp’s to portable across platforms. EdgeCore is developed with strict guide lines that only allow it to used API’s from this framework. However, EdgeApp may or may not be restricted to the CTEC framework. If not, this gives the developer the ability to create applications that can utilize other functions of the resident operating system.

As suggested above, an EdgeApp application can be a mixture of CalAmp and/or customer components. CalAmp is currently developing a library of CalAmp applications that may be used to add more functionality to the exist list of features provided by EdgeCore. This combined with the customer application(s) can provide a custom environment.

632

Note that CalAmp and Customer components can be selected via the menu config configuration tool, and this provides the third party developer the ability to create as many thread components as required.

739

A single customer component requires one or more threads and thus multiple components would mean multiple threads. Currently, EdgeApp application as a whole supports only threads that is hosted within the EdgeApp Appication. This means that on the Linux platforms, this is one executable or application virtual memory space.

EdgeApp on Linux platforms

EdgeApp on Linux based platforms run as the CalAmp user. CalAmp has regular account level privileges, not admin. However, applications are loaded by subsystems that have root privileges and such systems services are available via the API provided in the CalAmp SDK.

CalAmp Components vs. Example Components

A CalAmp Component is a component that provides a telematics service that is common to a number of customers. These components could be part of the EdgeCore core services, but to maintain a slim EdgeCore services model they are not. These CalAmp Compents and has been validated for quality operation in the same way that all CalAmp core services are quality tested. Each CalAmp component comes with the binaries only and the ability to integrate into the system using menuconfig.

Example components are developed simply to provide a knowledge based of the services that can be obtained from the EdgeCore, and CalAmp EdgeApp components. These examples are provided with the source code and can be included in the EdgeApp build using Menuconfig. It must be noted that these application, though still following best practices, are not fully QA’ed and are to be used as examples.

Both CalAmp components and CalAmp Example application can be combined together using menu config, and both have documentation to describe the operation, however Example apps should not be included in final end product distribution. Both CalAmp examples, and customer components should have best practices and quality analysis by the 3rd party implementer.

Template Component

The EdgeCore SDK includes a template component. This component is not buildable on its own, rather it is used to create new customer components. The associated script “create_new_comp.sh” allows the developer to auto generate code with the desired application name. It can be quickly added to menuconfig and built on the spot. Note that multiple customer application can be created, included and built.

Why Use Multiple Components?

CalAmp EdgeApp development environment includes the ability to create multiple customer components. Each newly generated component is a new thread instance within the EdgeApp application. Each component can then include as many threads that the developer wishes to include. So why have multiple components?

The answer is for modularity of deployment, there are not restrictions to having multiple components, once licensed for a EdgeApp development, multiple components are included. The advantage is for deployment. Multiple components is a clean way of the customer deploying what they want to different devices in the fleet. Ie, if there are three components, A, B and C. Then multiple arrangements can be made were there is an A + B, and A only or and A + B + C. Each of the components can be included using menuconfig, and different EdgeApp applications with different names/version can be then generated.

EdgeApp Process Models

The EdgeApp function in Edgecore is designed to support customer applications. As described in the introduction, the EdgeApp as a whole is broken into the Edgecore, EdgeApp Support, and the EdgeApp Components. EdgeApp itself will contain the IP or functionality developed by the third party developer. The EdgeApp Support portion is responsible for the download, deployment, and start/stop functionality of all the associated components.

EdgeApp is based on the generic CTEC Sub-System module. This framework includes the base application that is a standard platform process/task, has an entry point for startup and shutdown. It also interacts with the Edgecore system Watchdog, Message Bus, and Power State Management module and their basic handlers. The Edgecore EdgeApp Support Sub-System shall be a Edgecore application that supports

726
  1. DM-CTC Downloader download support - The EdgeApp Support package will register with the CTEC downloader process that it is EdgeApp capable, handle the download and deployment process to the target. EdgeApp runs under the CalAmp Admin account on Linux based platform.

  2. Complete doxygen documentation of EdgeApp, and all supported API Interfaces - The EdgeApp Support package will have a Doxygen main page that will include all the API,and Message BUS API, as well as all the documentattion on the SDK, tools, design references, and such.

  3. Support for broadcast of PEG triggers, Actions and other events via MBUS - Create additional Message Bus channels and Public APIs in the CTEC framework to support the requirements of EdgeApp , and Hosted App LMU32 Bit legacy application.

The EdgeApp Sub-System will be a complete build environment that contains the following components:

  1. Ubuntu ISO development environment 16.4 LTS - This ISO would contain the complete build tool chain in the form of the EdgeCore SDK, editors, debuggers and ubuntu development environment that can be put in a virtual machine for quick startup.

  2. EdgeCore SDK - This is the tool change for cross compliation and library support. It is included in the ISO, but is also released separately to allow EdgeCore updates to existing ISO VM instalations.

  3. The EdgeApp SDK - that provides the build binaries, libraries and source to start development. This also includes CalAmp Components.

  4. HTML based documentation - These are artifacts generated from the Edgecore build, and pushed to the EdgeApp repo to provide the required images for building. The documentation is a complete users guide and API documentation

  5. Example Application - to assist in quick startup of real customer applications.

Directory Structure

The directory structure of the EdgeApp Development SDK is shown below. The content of this folder is as follows:

487
  1. Deployment folder - This is simply the top level CMake description file.

  2. A Documentation folder - This folder contains Automatic Documented Doxygen generate HTML code that will include everything from API, interface specifications, to detailed descriptions of tools usage, development guidlines and reference material to get the developer up and running. This documentation is created in a Edgecore build,

  3. A Source folder - Containing all the source and binaries for the 3rd party developers to get started creating application.