The German Federal Ministry for Economic Affairs and Energy has undertaken one of the world’s more ambitious solar energy development projects. The AutoR Project (Autonomous Rim drive heliostat) was launched to offer innovative technology enhancements to the Concentrated Solar Power (CSP) world. The project’s goal is the development of CSP technologies that significantly reduce the cost of heliostat fields in order to make CSPs more cost-competitive and to promote widespread CSP deployment.

For the AutoR project, ADI TRINAMIC Motion Control developed a new heliostat architecture that implements three key improvements: 1) heliostat rim drive hardware that reduces weight and improves performance, 2) decentralized heliostat control with low energy consumption using PV (photo-voltaic) energy supply with battery storage, and 3) wireless heliostat control to reduce cabling cost, simplifying deployment and scalability.

This new and enhanced concept required an appropriate software platform for heliostats that would be highly autonomous. As such, it should require minimal communication from a centralized control system and perform all important tasks on its own. The structure had to be modular and adaptable to different hardware solutions, distributing the intelligence of the control server not only across the field but also within the different hardware components of the heliostat.

Hardware Architecture

The new heliostat OS was successfully tested with a rim-drive heliostat prototype in the Solarturm Jülich CSP research field in Germany. It tracked the sun using a wireless module that communicates with the centralized field control system through a mesh network made of similar devices, ensuring that the mirror facet reflected the sun on the CSP power tower that contains a central absorber to convert the produced heat into electrical power via heat exchangers and turbines.

Using the autonomous energy system and wireless remote control, the commands are sent by the operating system to two motion control drives which control both axes of the heliostat’s rims. A photovoltaic panel, battery and an Energy and Battery Management Unit (EBMU) which harvests energy out of the PV panel, charges the battery and supplies the energy to the autonomous system.

These components are connected together with a wired bus within each autonomous heliostat. One of the drives acts as master: it communicates wirelessly with the centralized field control system and with other devices, and runs the heliostat OS.

Software Structure

The software of the heliostat OS can be divided into several parts as shown in Fig. 2, with the kernel at its center carrying out the most important tasks, e.g. sun position algorithm, and coordinates the rest of the modules. It maintains the current mode of operation as a state machine and allows different behaviors and actions in the same mode.

Between the kernel and each axis is located the drive abstraction layer, transparently connecting the motion actions of the kernel with the drives. In AutoR, one axis is connected to the primary host board, whereas the second axis is controlled via RS485.

The parameter repository centralizes the control of all variables. It stores the values, updates them and delivers them to the kernel or the control system.

The command interpreter manages received commands from the central field control system and connects them to the matching functions of kernel and repository. It also manages reply and asynchronous messages.

Kernel

The heliostat kernel works as an advanced state machine that executes – either periodically or event-triggered – the corresponding actions for the implemented modes and events. It keeps a list of allowed transitions between modes for certain events. For example, the change mode function finds a proper transition defined by the group <Current Mode, Next Mode, Event>. In this case, the event is “Mode Change Command Received”. If there is any suitable transition, it will execute first the exit action of the current mode, and then the enter action of the new mode (if any). On the next periodical execution event, the action corresponding to the first run of the new mode will be performed.

Modes that require a single fast response can be triggered from the command interpreter directly, in order not to wait until the next periodical execution. Other events that cause actions in the kernel are, for example, an update of the set-point or the timestamp (they require a new calculation of the tracking point) or the reception of a calibration request.

In addition to the mode of operation, the kernel maintains a status variable. It indicates the mode phase and can be consulted by the central field control system. For example, Emergency Stow mode may be in the following statuses: in progress (rotating to safe position), in position (safe position reached) or locked (rims are locked in that position).

Modes

The kernel can operate in diverse power states, such us Off, Service or Night, in which several degrees of energy saving can be applied and operations like firmware update may be carried out. All these states occur when the heliostat is locked in a safe position. Once the state is changed to On, the modes of operation can be activated.

Table 1. Several Modes of Operation

Tracking Operation

Current time, absolute location of the heliostat, relative location of the tower, and position of the target. These are the only parameters needed, together with the sun position algorithm and the kinematic transformation, to calculate the position of the mirror that reflects the light to the required target.

The kernel can be configured to use one of several implemented sun position algorithms, according to the accuracy or the computation time. Up to now, the SPA and Grena algorithms are available in the OS.

The steps of the calculation are:

1. Computation of the vector to the target using location, tower distance and target position.
2. Calculation of the vector to the sun using location, current time and the sun position algorithm.
3. Addition of the two vectors to determine required mirror position.
4. Transformation of the mirror normal vector to motor angles and to motor positions using the kinematic transformation and gear ratio.

The kernel optimizes this process with the calculation of trajectories instead of only positions. It calculates the motor position for the current time and for a certain delay, e.g. 10 seconds. With these results, it creates a trajectory for each axis. Each trajectory is composed of an initial motor position (in motor steps), velocity (in motor steps per second) and the initial time. The relationship between these factors is represented in Equation 1.

MotorPos_Axis(t)=InitialMotorPos_Axis+(t-InitialTime)*Velocity_Axis

When the trajectory time is over, the kernel will repeat the calculation. Using this information, it can rotate the motors with constant speed or interpolate and adjust the position with a higher frequency.

Drive Abstraction

The connection of the kernel with the hardware-dependent software levels is realized through the drive abstraction layer. Commands such as moving the heliostat to a position, updating the speed or locking the rim, are sent to this layer, which is in charge of delivering it through the right path. This path can either be a direct function in firmware, or it can require issuing an RS485 request to another module and handling the reply.

Requests are not only addressed to the slave drive. The kernel may also ask the EBMU about the state of health of the battery, or the Wireless Module about the communication conditions with the central field control system.

Parameter Repository

The storage and management of all parameters in the heliostat OS are directed by the parameter repository. During initialization, it reads the values of the non-volatile variables (e.g. heliostat location and rain clean position) from the permanent storage. This module provides one interface to the kernel and a separate one to the command interpreter, so that both modules can read and write what that interface offers.

The most important parameters are:

• Defined positions such as horizontal, rain clean or locking position.
• Slow, track or fast velocities.
• Kinematic parameters and gear ratio of each axis.
• Tracking-relevant values like location, tower distance or set-point, temperature, humidity.
• Scram and stand-by offsets.

Command Interpreter

Commands from the control system are received via wireless device and arrive to the heliostat OS through the command interpreter. These commands belong to the Heliostat Application Protocol.

This module triggers the corresponding actions and changes to the received requests in the kernel (mode changes, calibrations, etc.) and in the parameter repository (value modifications or reading). It deals with diverse kinds of failures and lack of permissions. Not-allowed transitions between modes, actions requested in wrong modes or out-of-range value modifications of a parameter returning an error message to the command interpreter. The integrity of the received message is also checked in this module. In these cases, it will reply to the control system with the adequate error message.

Finally, the command interpreter is also in charge of issuing spontaneous messages (not triggered by the control system) of the heliostat OS, such as ‘calibration complete’ and ‘error report’.

Communication

The two protocols that have been defined to fulfill the communication requirements of the heliostat OS and the AutoR prototype are the Heliostat Application Protocol and the Intra-Heliostat Communication Protocol.

Heliostat Application Protocol

The communication between the heliostat OS (through the command interpreter) and the control system uses a specially designed application-level protocol, for which a command-set structure has been conceived. Flexibility and brevity are the two main purposes of the protocol. A flexible protocol is required since the concept of the heliostat OS and its functions are in continuous evolution. It has to be concise as well, because mesh network technology with 802.15.4 imposes a low maximum transmission unit (MTU).

Intra-Heliostat Communication Protocol

The hardware architecture of the AutoR heliostat calls for communication between different modules within a single heliostat. The master drive – running the heliostat OS – needs to communicate with the rest of the devices in order to gather information, command actions, and receive orders from the control system.

For this purpose, the Intra-Heliostat Communication Protocol (IHCP) has been designed. The drive abstraction layer and the command interpreter use it, as well as the firmware of the rest of the devices in the heliostat.

The basis of IHCP is the existing ADI TRINAMIC Motion Control Language (TMCL) with an enhancement to carry Heliostat Application Protocol commands as a payload. This special case occurs between the master drive and the wireless module. It also allows the wireless module to update the firmware of the rest of the modules.

The master of the RS485 bus is the master drive and the other modules act as slave in the communication. However, the wireless module needs to indicate to the heliostat OS that there are new requests waiting, which is why an interrupt line is available. When the wireless module activates the line, the kernel will detect it and issue a poll message. The wireless module will then finally be able to forward the message.

The formats of the IHCP request and reply are shown in Table 2 and 3 respectively. The drive abstraction layer uses standard TMCL instructions to communicate with the other modules in the network. Basic operations like rotate motor, read current position or velocity, check position reached, etc. are examples of TMCL operations. Other heliostat variables like the state of health of the battery or energy mode are also mapped into TMCL get parameter commands.

Table 2. IHCP Request Command Format

When the heliostat OS wants to poll for new messages or to send a spontaneous message to the control system, it writes a special code in the field “Command” (byte 2). From then on, that command will be treated as a special IHCP request with variable length and possibly an encapsulated request from the higher level in the payload.

Table 3. IHCP Reply Command Format

Design Benefits

The design of the heliostat OS together with the use of autonomous heliostats offer several advantages compared to centralized control systems that fully command heliostats via remote control. The main disadvantages of existing centralized solutions are that they are mostly bound by proprietary licenses or privately owned, and they lack modularity. As such, they don’t easily qualify for new projects and force the development of new control software from scratch. By contrast, the Heliostat OS concept with its modular approach makes an adaptation to any heliostat system or heliostat mechanical design quick and easy, e.g. through an update of the kinematic transformation. The much-reduced acquisition costs and the higher system dependability boost the development of new cost-sensitive CSP projects.

Despite the increased number of functionalities that the heliostat needs to carry out, the software footprint of the OS remains small enough (<200KB) to be used in small 32-bit microcontroller units (MCUs). A multitude of functionalities is spread out among various components of the heliostat that are equipped with MCUs and receive commands from the OS. Owing to this advantage, the design of the hardware is exceedingly flexible: making only a few necessary modifications, the OS can work on wireless or wired networks, with different mechanical designs and different energy sources.

The requirements of the control system of a heliostat field that is powered by this OS are considerably simplified. Therefore, one of several limitations concerning the field size is significantly reduced, making it possible to control many additional heliostats.

This enhanced system with widely distributed intelligence and autonomous heliostats only needs three things: a time update, a target point, and start-up prompt to start tracking accurately to the receiver. In addition to that, the heliostat OS provides an interface so that the functions can be overridden and controlled by the operator.

Thanks to its modularity, small footprint, and task distribution among the components, this design can be easily adapted to any hardware and mechanical architecture. The distribution of computing power across the field relieves the central system of many tasks, resulting in simpler field control and lower server requirements. Furthermore, the lower cost of ownership and high dependability make this solution ideal for new CSP projects.