In this section we review the commonly used terms about a device in KOS. Knowledge about these terms when we are developing devices using KOS is essential.
Term |
Description |
Device |
The collection of all hardware that works together as a single unit and is upgraded as an atomic unit. A typical device is a single box with a single node and several boards. If an expansion can be added that extends the functionality, the original unit and the expansion hardware is considered the device. Using KOS it is possible to build devices that appear as multiple devices but aren’t. Consider a distributed dispenser with a single controller under a counter and two heads. This may appear as three distinct devices, and they may even be purchased separately, but when combined, they form a single device. |
Board |
A piece of hardware that a node interfaces to, typically using a communication interface of some sort. Some boards may have a processor and run firmware, others may be simple devices running over standard interfaces such as usb, i2c and so on. If a piece of hardware can be detected, and/or updated, it is generally considered a board. Very simple hardware such as a switch connected to a GPIO pin is not considered a board. An LED connected to i2c may or may not be considered a board depending on the desired abstraction. |
Node |
A node is a linux based computer running KOS. Different nodes in a device can run different software, including different parts of the KOS stack. For example one node may run java while another only runs a browser. Nodes are connected to each other over ethernet and are able to communicate seamlessly, allowing a device to function as a distributed system. |
Primary Node |
Every device in KOS must have exactly one primary node. This node must run the java portion of the KOS stack and acts as the central hub for all other nodes within the device. The primary node manages the boot sequence for the entire device and ensures that every node and board in the device is running the correct software / firmware. The primary node also provides other centralized features such as time synchronization, network routing and so on. In a multi-node device, only the primary node is expected to have external connectivity. |
Node Type |
Every node in a device has a node type, which defines the role the node plays in the device. Consequently, the node type defines the software that will be installed on a given node. It is possible to have different types of hardware with the same node type. For example, if a board goes end of life and a new board is designed to replace it, there can be mixed hardware in the field. KOS is designed to support this use case, including the ability to switch to different board types as a field replacement and install all the necessary software on the new board without requiring network connectivity or any additional user intervention. |
Node Name |
Every node also has a node name. The node name acts as a qualifier to the node type to define a unique identity to every node in a device. For example, consider a device that has two identical heads. The heads would have the same node type as they perform the same function and run the same software, but they will have different names to distinguish them. This allows different nodes of the same type to potentially have different configurations if needed. |
Node manager |
Node manager is a native application that runs on every KOS node and is responsible for coordinating the boot process of the node as well as managing node synchronization. The role of node manager differs between primary and secondary nodes. On a primary node, once KOS boots to user space, node manager continues the boot process by launching the java portion of KOS. The system application for the primary node is launched and java allows connections from secondary nodes. On a secondary node, when node manager is started it attempts to connect to the primary node of the device. Once connected, the primary node will verify the software installed on the secondary node, updating and rebooting the node if required. Once the software has been verified correct, the boot process will continue normally and the secondary node launch application code. While the device is running, all node manager instances remain connected to the primary node which allows the primary to coordinate device-wide operations such as reboot, software install and so on. When running in test mode, node manager also acts at a client for KOS Studio. Node manager provides automatic node discovery within studio, provides studio with target information, and provides a mechanism for studio to install new software seamlessly across the network onto the device. When developing java applications, node manager also coordinates remote debug sessions from standard java IDE’s. |