Moving extremely heavy loads with radio remote control in areas with personnel traffic always has a risk associated with it. There are numerous ways to reduce the risk through safety systems and additional peripheral equipment. The companies KUKA and STW have jointly developed a new type of monitoring for a floor conveyer without a driver cabin. In this article a method is described, that illustrates how safety is achieved through a certified safety application in a freely programmable controller intended for safety relevant applications. 

KUKA omniMove is the designation for an extremely agile type of drive for a floor conveyer. With its electric drives, the KUKA omniMove provides unlimited manoeuvrability in all directions as well as rotation in place. Through its omni-directional drive wheels the vehicle may be freely navigated and steered in all directions by remote control, even in the narrowest spaces, with a positional accuracy of up to ±1mm. Compared to conventionally steered wheels the logistics area required can be reduced by up to 50% and the production area correspondingly increased.

The omniMove wheel has a special rim with vaulted rollers mounted on the periphery. Positioned at a 45° angle, when the wheel is driven, two power components result, that are parallel and perpendicular to the drive axis. Through diverse turning directions of the wheels, some of the power components compensate each other over the chassis while others combine to determine the motion of the vehicle. Thus, in addition to straight, sideways, and diagonal travel, it is also possible to move in any curve or rotation around a freely defined middle point.

The KUKA omniMove vehicles are for internal logistics and can lift loads up to 100 metric tons. There are ten different vehicle models with numerous customer specific options to meet any requirement. Anywhere from 4 to 20 drive wheels as well as numerous additional load wheels can be configured in order to facilitate the transport of very large, unwieldy components. 

Description of the 3XL Controller

KUKA needed to find a control system that would operate with many types of vehicles and fulfil customer specific requirements. For many years Sensor-Technik Wiedemann (STW) has offered fast and flexible control solutions in mobile applications with its ESX family of controllers. STW has continued this successful series with the ESX-3XL 32-bit controller. The ESX-3XL was conceived to provide a high level of flexibility. With up to 6 internal expansion boards, 84 of the 162 possible connector pins can be configured with distinct functions, from simple I/O to encoders, special I/O, data storage and communication interfaces. The mainboard of the ESX-3XL also offers software configurable I/O functions. The 28 available inputs are all 12 bit multi-functional inputs (MFI), i.e. their function can be defined by the application programmer. Initialisation functions allow the programmer to specify each input as an analogue current or voltage input (measurement range 5V, 10V or 40V) or as digital/RPM (frequency) input. Furthermore, the 3XL software library allows an application specific function to be called when the input signal changes (callback function). The RPM signal covers frequencies from 0.6Hz to 20kHz. Filtering may be applied to the MFI signal through software, with configurable debounce times and low pass filters.

All outputs can produce PWM signals, are protected against short circuit and are controllable via 12 bit current measurement and status feedback for complete diagnosis. 

The core of the ESX-3XL is a 150 MHz Tricore processer with 4MB RAM, 6 MB flash memory and 32KB EEPROM parameter memory. The mainboard has 4 CAN interfaces and a serial (RS-232) port. Additional communication interfaces (including Ethernet and USB) may be added by means of the expansion boards.

Functional Safety

Recent experience with numerous applications has shown that the customer requirements for functional safety are growing. With increased integration of controller and memory components, safety requirements may be fulfilled in an economically viable manner, alongside the normal functionality. Where does the need for functional safety oriented electronic controls originate? These controllers reduce the risk of serious accidents in applications that include functions relevant to the safety of people and things in the environment. This assumes, of course, that the criteria for functional safety are correctly fulfilled. “Safe” is defined here as a situation where the risk is smaller than the generally accepted risk limit. An acceptable risk level is defined for the application. This risk is determined by a combination of the probability of occurrence and the severity of the damage.

Functional safety is a part of the overall safety of a system that depends on the electronic systems, other safety technologies, and external risk factors. The requirements on the functional safety must be defined before certification can take place. Which safety standards should be applied? The standards are mostly defined by the application. The application described here is a floor conveyer, which can transport loads of up to 100 metric tonnes. Therefore this vehicle must meet special safety requirements floor industrial trucks with respect to braking distance and subsequently the maximum allowable vehicle speed.

The risk analysis of this application resulted in performance level “PL c” from the guidelines for machine safety DIN EN ISO 13849-1 as being applicable for the KUKA omniMove. STW developed the safety requirements and a safety plan for the omniMove and the Institute for Work Safety IFA in Sankt Augustin approved the requirements. 

In the current project these conditions are implemented with a safety oriented software module on the ESX-3XL electronic controller. For that software module the requirements for safety relevant application software according to DIN EN ISO 13849-1 apply. The safety architecture is conceptualized based on Category 2 of the standard. The control unit consists of a freely programmable main controller and an independent system supervisor (SSV). The SSV is also a programmable controller that monitors the main controller by assuming watchdog functionality, monitoring system voltage, testing logical events and thereby allowing the utilization of the controller in safety critical applications. The main controller has diagnostic routines that continuously check the entire system in hardware and software and place the system into a safe condition in the event of a failure. The safe condition in this application is emergency stop. 

The KUKA omniMove vehicles can reach speeds up to 6 km/h, depending on the type. The risk analysis however produced significantly lower allowed maximum speeds. Two conditions for maximum speed limits are described.

The first condition is for the load condition. For an empty vehicle the maximum allowed speed is 3 km/h, which is the normal walking speed of a pedestrian (for example, the operator with the remote control unit). For a loaded vehicle the maximum allowed speed drops to 1 km/h. 

The second condition pertains to vehicles that are outfitted with laser scanners that create a protection zone around the vehicle. Laser scanners can bring a vehicle to a stop as soon as they sense an obstacle (e.g. personnel) in the path. There are situations where the laser scanner must be switched off (override conditions), for example driving through narrow warehouse spaces. To guarantee the safety under these conditions the maximum allowed speed is reduced to 0.1 km/h.

The maximum allowed speeds are specified based on defined stopping distances during an emergency stop. The omniMove vehicles are intended for many very different tasks, meaning a large number of design variants and operational situations. The risk evaluation can therefore also differ significantly, and so the maximum speed must be adjusted. The maximum speed is set individually for each vehicle type through software parameterisation.

The Safety Concept

The safety oriented software module for speed monitoring has 3 tasks:

• Identify the currently allowed maximum speed
• Calculation of the actual speed of the vehicle from the available signals from 3 wheels, the 4^th wheel providing redundancy in the speed measurement.
• If the actual speed is too high or any other fault is sensed, an emergency stop must be initiated immediately.

The system KUKA ordered from STW

The name of the system developed is “omniMove Speed Surveillance System” and is abbreviated OM3S. OM3S has the following core tasks (functional requirements)

• Reliable recognition of the load condition of the vehicle by redundant load sensors.
• Reliable recognition of the status of the laser scanner protective field (active or overridden) by redundant signal paths.
• Determination of the currently allowed maximum speed based on load condition and override information.
• Reliable reading of the encoder signal from the individual drive wheels of the vehicle through redundant sensors with analogue and/or digital outputs.
• Calculation of the actual speed of the vehicle from the drive wheel encoders. This can be accomplished by a mathematical model with the x, y coordinates and the instantaneous rotational velocity of the 3 drive wheels.
• Fault recognition through plausibility check.
• Every recognized fault or a speed in excess of the presently allowed maximum speed must result in an emergency stop for the vehicle (the safe state).
• The monitoring software must be suitable for all conceivable configurations (geometry, size, number of driven and auxiliary wheels, etc.) of the vehicle.

In order for the OM3S to meet the requirements of safety software with performance level PL-c according to DIN EN ISO 13849-1 the following quality attributes must be fulfilled:

• The parameters loaded in non-volatile memory (EEPROM) must be verified with CRC checksums
• The integrity of the main memory (RAM) must be ensured through suitable means.
• Program flow control must be monitored with a system supervisor with watchdog functionality to guarantee the correct program processing.

Among the overall requirements for OM3S is the prerequisite that OM3S be implemented on the PL-d certified STW safety ESX-3XL controller with integrated hardware diagnostics. The STW ESX-3XL hardware diagnostics is divided into 2 parts:

• Start-up diagnostics that occur when the controller is switched on and test all of the basic functions, for example the safety relay. These tests cannot be repeated at a later time because they would affect the operation of the vehicle.
• Periodic tests of memory and CPU for the integrity of content and function, which run in the background, parallel to the application software.

In this project KUKA already uses the STW ESX-3XL controller, to run the vehicle’s application software. The OM3S will also run on this controller with interfaces to:

• The vehicle control software from KUKA, and,
• The Hardware Abstraction Layer (HAL) of the ESX-3XL.

STW Development Process

The development process of safety software according to DIN EN ISO 13849-1 follows the V-model.

Requirements Engineering with Requirements Management Software 

The specifications of this project are processed exclusively in database oriented requirements management software. This promotes the atomic capture of individual requirements (individual entities) that are referenced by number and can be individually tested. This leads to testable requirements and traceability of the individual requirements through the life cycle of the application and back to their origin or source.

Specification Reviews

The individual requirements go through formal reviews by various working groups based on the following criteria, and the results are documented so that they can be incorporated into subsequent versions of the specification:

• Unambiguity
• Completeness
• Testability

Architecture and Review

The system architecture must be designed before the design of the individual software components. A second software architect from outside the project must review the architecture and then it can be refined.

General Information on Architecture Reviews

Frequent and early reviews prevent the development effort going in the wrong direction or into a dead end. Through the process of explaining ones’ own design to another person, shortcomings in design will become evident. It will be clear whether the underlying considerations are logical and complete.

Reviews also uncover misunderstandings, differences in interpretation or incompleteness of the requirements. Reviews during the design process should be done to explain the solution, why it was chosen, what alternatives there were, and why they were not chosen. In this way the work of the architect can be reproduced and either confirmed or corrected. The review is an important test that can prevent errors from being propagated.

Embedded Unit Tests (Component Tests)

There must be a Unit Test written for each function that is implemented in a software component. Thus, each software change can be tested completely and preferably automatically. This ensures that all previous functions still work error-free after the change.

System Test Specification and Implementation

After the requirements are put in the specification, they are evaluated for testability. System tests will then be defined for testable requirements in a System Test Specification.

Configuration Management

A configuration manager is assigned to administer the system configuration and to maintain an overview of which versions of the individual development components (Specifications, Architectural Designs, System Test Specifications, Implementation, Test Protocol) go together.

Test Management

The importance of the software tests is emphasized with identification of a Test Manager. The Test Manager will be assigned this role by Project Management. He produces a test management plan, organizes the tests and coordinates the activities of the software testers.

Defect Management

The software testers also have the task of managing defects. The defects must be entered into a ticket system. Once entered, the processing of the defects will be systematically tracked, with their status (e.g. Developer Analyzing, Tester Confirmed Resolution, etc.)

Change Management

Once a first version of the specification is completed and released, work can begin on the software architecture and system test specification. In practice, work can begin earlier when a stable set of requirements have been identified. After this, desired changes can only be introduced through a change management system. Each change request is entered into the ticket system and must go through a series of different status conditions before it is finally approved and implemented.

Commissioning

With the conditions for functional safety fulfilled, the omniMove should operate without unnecessary interruption. The availability of the machine is a very important benchmark for the customers. Initial tests showed that the availability was too restricted.

In order to improve the availability, the safety application was modified to compensate for unexpected effects from vibration in the vehicle and the effect on the wheel speed measurement. Filtering of the wheel sensors was required to ensure a stable evaluation of the actual vehicle speed. Multiple drive tests, extensive technical discussions with safety experts and eventually modifications to the OM3S specification were necessary to find a technical and commercially viable solution, and deliver a successful, safe, product.

Conclusion

The software application fulfilled all aspects of functional safety, while maintaining both the availability of the system and the flexibility in terms of the large number of vehicle variants. Parameterization of the software is a necessary part of the safety considerations, and ensures the flexibility to accommodate future customer requirements, and the inherent changes to the risk situation.