Development Plan March 2019

SYSTEM DESIGN DOCUMENT

1 INTRODUCTION

1.1 Purpose and Scope
The Systems Design Document’s purpose is to describe the compact electrode
boiler prototype design. This document will be updated to reflect the current
state of the development and to incorporate changes due to new learnings as
the development progresses.

1.2 Project Executive Summary
The compact electrode boiler prototype will be used to demonstrate our
technologies capabilities. Although more widely applicable, the driving
application for the prototype is to be able to heat a cup of water to make tea in
5 seconds or less. This would be of great advantage to restaurants who
specialize in serving hot beverages such as numerous coffee shops.

1.2.1 System Overview

Water Inlet

User Interface Flow Meter
Controller
Temperature
240 ~ System A Sensor
Controller V
Water
AC Voltage Heating Cell
Controller
Temperature
Sensor

Grounding
Shield/Plate

Water Outlet

The compact electrode boiler will be powered from an AC source. The boiler
consists of:

● User Interface
● System Controller
● AC Voltage Controller
● Water Cell
● Sensors
1.2.1.1 User Interface
The user interface accepts user input for target water temperature and
starting/stopping the boiler. It provides real-time information to the user such as
water temperature, flow rate, and drive capacity. Diagnostic information will also
be displayed to aid in testing.

The user interface has a microcontroller to control the display and respond to
user inputs such as buttons and keypads.

The use interface communicates with the system controller over an embedded
serial interface.

The user interface is powered from a dedicated low voltage DC power supply.

The user interface is galvanically isolated from the other parts of the system.
1.2.1.2 System Controller

The system controller accepts inputs from the control interface and various
sensors.

The system controller evaluates sensor inputs and generates the appropriate AC
Voltage Controller input signals to heat the water to the target temperature
provided by the control interface.

The system controller evaluates sensor inputs and determines if other
subsystems are within allowable operating conditions. If conditions fall outside
the limit values actions are taking to protect the system from damage. Error
conditions are logged and users are notified via the control interface.

The system controller is powered from a dedicated low voltage DC power
supply.
1.2.1.3 AC Voltage Controller
The AC voltage controller regulates the voltage applied to the water cell. No
rectification or frequency conversion is performed.

Control of the applied AC voltage allows the system to regulate the current into
the water cell and ultimately the power.
1.2.1.4 Water Cell
The water cell is where heating of the water occurs.

The water cell allows current to pass through the water which heats it due to the
resistive losses within the water.

The water cell is a collection of opposing electrodes arranged such that water
can flow between them.

The resistance of the cell is specifically designed to meet the heating and flow
requirements for variable water conditions.
1.2.1.5 Sensors
Temperature sensors are located at the water inlet and outlet locations. These
sensors are monitored by the system controller to determine the required
energy for heating. The outlet temperature is used to verify that the target water
temperature is being reached.

A flow sensor (or pressure sensor if the water cell is well characterized) is placed
at the water inlet. This sensor is monitored by the system controller to determine
the energy required for heating.

An AC RMS voltage sensor is placed in parallel with the water cell. An AC RMS
current sensor is connected in series with the water cell. These two sensors allow
the power into the water cell to be monitored.

1.2.2 Design Constraints
● Must operate from commonly available AC power in target market
(240Volts, 40Amps)
● Should be easily integrated into end use products
○ Well documented serial interface with API for configuring and

operating system
● Water cell design should be parameterized so that it is easily scaled for

different applications with a minimum of design change.
● Well-characterized operation with detailed specification sheets available

to customer engineering teams for system design purposes.

1.2.3 Future Contingencies
[TBD: …]

1.3 Glossary

AC Alternating Current
DC Direct Current
EEPROM Electrically Erasable Programmable Read-Only Memory

2 SYSTEM ARCHITECTURE

2.1 System Hardware Architecture

LOW MICROCONT TEMPER HIGH
ROLLER ATURE
EEPRO CURREN
M TEMPER T
ATURE VOLTAG
To UART E
User INTER PRESSU VARIABL
RE E AC

VALVE
(outlet)

WATER
CELL

GALVANI
C

2.1.1 Microcontroller
The microcontroller implements a command API over a serial interface that
supports configuration and control from an external system. The interface also
supports event messages to notify the external system of operating
conditions/states and alarm events.

The microcontroller determines how much power to deliver to the water cell
using the water inlet temperature and pressure as well as the target water outlet
temperature. During heating all parameters are monitored to ensure the target
outlet temperature is reached. Adjusting the water cell’s applied voltage
through the variable AC controller controls the amount of heating.

A valve at the outlet is actuated to release water from the system during
heating.

2.1.2 EEPROM
An EEPROM is used to store device manufacturing information, calibration data,
and user configuration data.

2.1.3 Temperature Sensor
Temperature sensors must be inserted in the inlet and outlet water streams.
These sensors are monitored by the microcontroller to determine the amount of
heating required and to verify that target temperature has been reached.

2.1.4 Pressure Sensor
A pressure sensor inserted in the inlet water stream is used to determine flow
rate. Flow rate is determined using pressure and the pressure vs. flow rate data
of the attached water cell.

The pressure sensor is also used to alert the external system of out of range
pressure conditions. Pressures which exceed the operating range will cause the
system to dispense water that is too cold as the system cannot deliver enough
power to meet the required heating demands. Pressures that are below the
operating range will cause water to be dispensed at the correct temperature but
under the target output flow rate.

2.1.5 Current Sensor
A current sensor measures the current flowing into the water cell. The output is
used to determine the power flowing into the water cell.

This sensor is an input to a control loop and must have a suitable bandwidth.

Both DC and AC currents should be sensed. The AC current is dominant in the
heating of the water cell. A DC current can indicate electrolysis is occuring which
degrades the electrodes and creates oxygen and hydrogen gas. When DC
current is sensed it may be possible to nullify it by introducing an offsetting DC
voltage.

2.1.6 Voltage Sensor

A voltage sensor measures the voltage applied to the water cell. The output is
used to determine the power flowing into the water cell.

This sensor is an input to a control loop and must have suitable bandwidth.

2.1.7 Variable AC Controller
The variable AC controller reduces the input AC voltage to a level commanded
by the microcontroller. This allows the microcontroller to adjust the voltage
applied to the water cell. Since the water cell is primarily resistive this effectively
controls the power into it.

2.2 System Software Architecture

2.2.1 Command API
[TBD: Discuss message passing, message format, message generation, error
checking, events. Details are in a later section.]

2.2.2 Heat Control Loop
The heat control loop consists of a …

[TBD: Inner power control loop
● ○ Inputs: Current, Voltage
○ Output: Variac level
●
Outer temperature control loop
● ○ Inputs: Inlet temperature, Outlet temperature, Inlet pressure
○ Output: Target power
]
Bandwidth
○ Power loop = 180Hz (maximum Variac update rate)
○ Temperature loop ~= 20Hz

2.2.3 Safety

3 INTERFACE & COMMAND API

3.1 Inputs
[TBD:
● Serial interface
● GPIO??
]

3.2 Outputs
[TBD:
● open-drain alert flags?
]

3.3 Commands

3.3.1 System

3.3.2 Configuration

3.3.3 Operation

3.3.4 Events

3.3.5 Alarms

4 DETAILED DESIGN
This section provides the information needed for a system development team to
actually build and integrate the hardware components, code and integrate the
software modules, and interconnect the hardware and software segments into a
functional product. Additionally, this section addresses the detailed procedures for
combining separate COTS packages into a single system. Every detailed
requirement should map back to the FRD, and the mapping should be presented
in an update to the RTM and include the RTM as an appendix to this design
document.

4.1 Hardware Detailed Design
A hardware component is the lowest level of design granularity in the system.
Depending on the design requirements, there may be one or more components
per system. This section should provide enough detailed information about

individual component requirements to correctly build and/or procure all the
hardware for the system (or integrate COTS items).

If there are many components or if the component documentation is extensive,
place it in an appendix or reference a separate document. Add additional
diagrams and information, if necessary, to describe each component and its
functions, adequately. Industry-standard component specification practices
should be followed. For COTS procurements, if a specific vendor has been
identified, include appropriate item names. Include the following information in
the detailed component designs (as applicable):

● Power input requirements for each component
● Signal impedances and logic states
● Connector specifications (serial/parallel, 11-pin, male/female, etc.)
● Memory and/or storage space requirements
● Processor requirements (speed and functionality)
● Graphical representation depicting the number of hardware items (for

example, monitors, printers, servers, I/O devices), and the relative
positioning of the components to each other
● Cable type(s) and length(s)
● User interfaces (buttons, toggle switches, etc.)
● Hard drive/floppy drive/CD-ROM requirements
● Monitor resolution

4.1.1

4.2 Software Detailed Design
A software module is the lowest level of design granularity in the system.
Depending on the software development approach, there may be one or more
modules per system. This section should provide enough detailed information
about logic and data necessary to completely write source code for all modules in
the system (and/or integrate COTS software programs).

If there are many modules or if the module documentation is extensive, place it in
an appendix or reference a separate document. Add additional diagrams and
information, if necessary, to describe each module, its functionality, and its
hierarchy. Industry-standard module specification practices should be followed.
Include the following information in the detailed module designs:

● A narrative description of each module, its function(s), the conditions under
which it is used (called or scheduled for execution), its overall processing,
logic, interfaces to other modules, interfaces to external systems, security
requirements, etc.; explain any algorithms used by the module in detail

● For COTS packages, specify any call routines or bridging programs to
integrate the package with the system and/or other COTS packages (for
example, Dynamic Link Libraries)

● Data elements, record structures, and file structures associated with module
input and output

● Graphical representation of the module processing, logic, flow of control,
and algorithms, using an accepted diagramming approach (for example,
structure charts, action diagrams, flowcharts, etc.)

● Data entry and data output graphics; define or reference associated data
elements; if the project is large and complex or if the detailed module
designs will be incorporated into a separate document, then it may be
appropriate to repeat the screen information in this section

● Report layout

4.3 EXTERNAL INTERFACES

External systems are any systems that are not within the scope of the system under
development, regardless whether the other systems are managed by the State or
another agency. In this section, describe the electronic interface(s) between this
system and each of the other systems and/or subsystem(s), emphasizing the point
of view of the system being developed.

4.4 Interface Architecture

In this section, describe the interface(s) between the system being developed and
other systems; for example, batch transfers, queries, etc. Include the interface
architecture(s) being implemented, such as wide area networks, gateways, etc.
Provide a diagram depicting the communications path(s) between this system and
each of the other systems, which should map to the context diagrams in Section
1.2.1. If appropriate, use subsections to address each interface being
implemented.

4.5 Interface Detailed Design

For each system that provides information exchange with the system under
development, there is a requirement for rules governing the interface. This
section should provide enough detailed information about the interface
requirements to correctly format, transmit, and/or receive data across the

interface. Include the following information in the detailed design for each
interface (as appropriate):

● The data format requirements; if there is a need to reformat data before they
are transmitted or after incoming data is received, tools and/or methods for
the reformat process should be defined

● Specifications for hand-shaking protocols between the two systems; include
the content and format of the information to be included in the hand-shake
messages, the timing for exchanging these messages, and the steps to be
taken when errors are identified

● Format(s) for error reports exchanged between the systems; should address
the disposition of error reports; for example, retained in a file, sent to a
printer, flag/alarm sent to the operator, etc.

● Graphical representation of the connectivity between systems, showing the
direction of data flow

● Query and response descriptions

If a formal Interface Control Document (ICD) exists for a given interface, the
information can be copied, or the ICD can be referenced in this section.

5 SYSTEM INTEGRITY CONTROLS
Sensitive systems use information for which the loss, misuse, modification of, or
unauthorized access to that information could affect the conduct of State
programs, or the privacy to which individuals are entitled.

Developers of sensitive State systems are required to develop specifications for the
following minimum levels of control:

● Internal security to restrict access of critical data items to only those access
types required by users

● Audit procedures to meet control, reporting, and retention period
requirements for operational and management reports

● Application audit trails to dynamically audit retrieval access to designated
critical data

● Standard Tables to be used or requested for validating data fields
● Verification processes for additions, deletions, or updates of critical data
Ability to identify all audit information by user identification, network terminal
identification, date, time, and data accessed or changed.