noFilis

CrossTalk Engine Interfaces

The basic architecture of CrossTalk consists of the CrossTalk Engine and a set of dynamic interfaces around it.

Monitoring

Monitoring is a major component of CrossTalk since it is designed to support continuous operations. At the core of CrossTalk are independent MicroProcesses that start automatically as CrossTalk starts and
immediately begins to manage and execute their components.

CrossTalk monitors the bundle of services and elements of all processes. Services consist of a heartbeat. Devices are monitored by timers via polling. An alert is raised after notification of a component failure or non-responding components.

All messages are reported to the CrossTalk Monitor. CrossTalk itself can be monitored by a central SAP alert monitor such as SAP CCMS*, IBM Tivoli*, or Hewlett-Packard OpenView*, using HTTP or SNMP.

CrossTalk Architecture

CrossTalk is based on a modular, robust Java architecture. All components are designed for high
availability and optimized hardware resource use. The scalable system is designed to control hundreds of devices in distributed locations.

Core part of CrossTalk is the CT (CrossTalk) Engine, which implements the basic functionality to run device processes. The CT Engine can be run and executed directly on a RFID reader device, on a PLC (Programmable Logic Controller) System on a industry PC in a production environment or, together with SAP AII middleware, in a computer center or even distributed over several locations.

Operation, configuration and monitoring of the whole environment can be done by a central CrossTalk instance.

The CrossTalk Engine works partially in real-time. After the system starts, all necessary
components (e.g., processes, device connections) are started and monitored automatically.
Configuration and monitoring are done via the CrossTalk web interface.

All required configurations are stored in the CrossTalk config repository. In most cases, the resource requirements for the database are very small and an already existing system instance can be used. For detailed system requirements please refer to the CrossTalk product sheet.

MicroProcess System

Automated operation of devices and information flows is controlled by CrossTalk MicroProcesses. The MicroProcesses are a highly flexible and robust tool which can be used to solve all operational requirements and devices.

The MicroProcess working model is used to design processes. This consists of process elements, services, and devices, which are linked by the connectors. Every element has its own property confi guration and monitoring function. Services with a ServiceControl Interface can display attributes, activities, and actual status at run time.

A MicroProcess, for example, can monitor a sensor and switch on a reader to be able to read tags. The captured data may then be filtered, transformed, and sent to the next layer.

Next, the reader is switched off, the sensor is reset, and a message is sent to a signal or display. All these activities and services can be combined into a single process, which can then be easily integrated into the running RFID environment. CrossTalk visualizes and simplifies these complex processes by supporting the creation, display, management, and reporting of these MicroProcesses.

Basic Components

Component	Functionality
DeviceDriver	Takes care of a transparent connection of different HW components, like RFID Reader, I/O Controller .... This means a standardized functional layer between device and software. All devices can be accessed by the same CrossTalk commands in the same format. A read or write command works in the same way for all supported devices.
DeviceManager	TheDeviceManager establishes the connection to a device and watches and monitors this connection
ServiceManager	Services are small software components. During operations they control the device and the information exchange. The ServiceManager takes over the responsibility for the whole life cycle of the service, f.e. registration, start, stop or monitoring the heartbeat of the services.
MicroProcessManager	Devices and services are connected to a micro process. The ProcessManager is responsible for the processes' life cycle.
Monitoring	Monitoring means visualization and reporting of devices, services and processes.
ScriptingEngine	On top of the DeviceDrivers, which are the standardized functional layer for the devices, Scrpits can be executed. Single device functions ( Reader.read() ) can be bundled to a JavaScript compatible script. The ScriptingManager executes these scripts.