 | |||||
| Forum | Solar-Today | Wood-Today | Burn Planner | ||
Introduction
This page describes the software design. There are also pages that describe the logic and operation of the software:
- Presentation describing the control system actions during the life of a fire.
- Description of heating system mode management.
- Description of oil boiler heat scavenging.
- Description of domestic hot water heater management.
- Description of wood boiler management.
Environment: Controller Card
The control system software runs on a Technologics TS-7260. This card comes with a stripped-down Linux installation in flash memory including the Apache web server. The processor is a 200MHz ARM-9. It has 32mb of ram and a 32mb flash drive. This places constraints on the size and complexity of software that can be used. The card will boot up to a serial console as delivered. This page offers a more complete description. The first task is to configure the card.
Initial configuration of the card includes network setup, installation of libraries, web server configuration, and other tasks. Software development is performed on a Linux workstation, and files are stored on a Linux server which also hosts a MySQL database. The /home directory from the server is mounted as /home on the TS7260. Executables and the TS7260 webserver are configured to run from directories under /home.
On the other side of the Atlantic, Jim Jackson has done great work in figuring out how to work with these cards and documenting his findings. His ARM web page is a valuable resource. In particular, the cross-compilation techniques that he describes are the foundation for work on this project.
Environment: External Hardware
In addition to the resources of the controller card, the system has two TS-9700 A/D cards providing a total of 16 channels of analog input and a TS-DIO64 providing 64 channels of digital I/O.
The oil boiler and wood boiler both have their own built-in controllers. These controllers manage combustion and circulator pump operation when either boiler is operating. These controllers are independent of the TS-7260. The software has no access to their internal states and no direct ability to affect their operation.
Environment: I/O
The following I/O is available to the system:| Analog Input | Description |
|---|---|
| Storage tank bottom | Temperature 6" above external storage tank bottom |
| Storage tank middle | Temperature at midpoint of external storage tank |
| Storage tank top | Temperature 6" from top of external storage tank |
| Solar in | Temperature at storage tank inlet from solar panel |
| Wood out | Temperature at outlet of wood boiler |
| Wood in | Temperature at inlet of wood boiler |
| Oil out | Temperature at outlet of oil boiler |
| DHW | Temperature of domestic hot water heater tank, at midpoint |
| Combustion | Wood boiler combustion chamber temperature |
| Digital Input | Description |
| 'Demand' | High-priority zone (living space, DHW) needs heat |
| Hot Tub Warm | Hot tub is at desired temperature |
| Hot Tub Comfort | Is heating the hot tub a priority? |
| Oil/Wood switch | Has user elected to disable oil burner? |
| DHW Warm | Is the Domestic Hot Water tank at temperature? |
| Top Floor Warm | Is the top floor of the house warm? |
| Main Floor warm? | Is the main floor of the house warm? |
| Bottom Floor Warm | Is the basement warm? |
| Digital Output | Description |
| DHW force | Force the DHW zone valve open - superheat the DHW tank |
| Hot Tub Control | Assert computer control of hot tub zone valve |
| Wood mode force | Disable control inputs to oil boiler |
| Wood recirc | Open bypass valve to allow water recirculation through wood boiler |
| Tank circulator | Turn on storage tank circulator pump |
| Tank Zone Valve | Open storage tank zone valve |
| Hot Tub Zone Valve | Open hot tub zone valve |
| Oil circ force | Turn on oil boiler circulator pump |
Software Architecture
The TS7xxx cards are remarkable, but they do have their limitations. Limited memory, no hard disk, and no floating point all limit the card's ability to act as a general purpose computer. The software architecture must take into account these limitations as well as the most important design goal: The system must be able to perform it's basic control functions despite any reasonably likely failure. For the purposes of this discussion, 'failure' includes network failure, power failure, and abnormal termination of a software task.
- Power failure is addressed in the hardware section.
- Network failure tolerance is accomplished by having a skeletal /home directory 'underneath' the /home mount point, so critical files are available even if the network is down. None of the executables perform any file I/O except at startup.
- Abnormal termination is addressed by partitioning the software into small, simple, and independent programs.
Small, simple programs are easier to test and are more reliable than large programs. In this design, programs are completely independent, and communicate with each other through a 'shared memory' area described in more detail below. Only one executable is truly necessary for basic control functions.
These are the four basic programs. There are links provided to the actual source code for each.
- I/O Task: A very simple C program running as a 2Hz background task that handles physical I/O and low-level (think brainstem) control functions.
- Control Task: A higher level C program running about once every 30 seconds that contains the higher level / more complex logic and control functions
- Datalogger Task: A C program that performs datalogging - writing selected data to a relational database on a remote server.
- Web Interface: A CGI script in C that allows a web user to view system status and set various control parameters
All the software is under development, and may not agree perfectly with the web site. The web site reflects design goals, while the software may not yet implement all the planned functionality. Source files are available here. The initial implementation is a simple solar hot water heater with a circulator pump managed by the controller.
Shared Memory
All of the above programs communicate and share data via a shared memory area. Only the I/O task interacts with the actual hardware. In the distributed Linux kernel, shared memory areas appear to be limited to 256 bytes. Shared memory contains two arrays: one array with three values for each analog input, and a second array with two values for each block of eight digital I/O lines.
Analog inputs are 12 bits. The shared memory area has a 16 bit location for the raw value as read from the card, and a floating point location for the calculated temperature. There is also a character location that contains status information (out of range / inactive).
The digital I/O array has an entry for each block of eight I/O lines. Each block contains a byte for I/O values and a byte to define direction for each line.
I/O Task
This task is launched at startup. It reads thermistor lookup table data and calibration data. It creates the shared memory area that all tasks use.
It also handles all basic safety-related logic (circ pump control, fan control, safety interlocks, overtemp) so that safe operation can be assured with only this program running.
In the initial implementation, this task reads analog values from the TS9700 into shared memory, and performs digital I/O to and from shared memory.
Control Task
This module contains the mode logic that sets zone priority, makes oil/wood decisions, and determines major and minor operating modes. It does not communicate directly with hardware, only with shared memory.
Datalogger Task
The datalogger simply reads data from shared memory and writes it into a database. For a sample of logged data, visit the performance data page.