RED Systems' Technology
 

| Home | Highlights | Intro | Objective | System | More |

 

| General Issues And Design Goals | Basic System Components |

     
 
Front-end unit
  Concept
  Components
 
  seismic sensor
  master unit
  extension modules
  power supply
Radio Link
Data processing
Alert messaging
Remote terminal
 

Basic System Components > Front-end unit > Components

Master Unit

The master unit will be designed in such a way that a certain number of discrete electronic modules can be hosted “under the same roof.” An adequate solution has been found: a cabinet with a central motherboard, called an MCC (Module Carrying Chassis).

Master Unit: click to enlargeThe motherboard, a large PCB, serves as a mechanical platform as well as an electrical interconnect carrier. (See MCC cross section, which shows the motherboard in red.) Both sides of the PCB can accept plug-in modules, one forming a private compartment with restricted access, and the other side being open to more general access.

A comprehensive shield covering the entire system is provided by the pyramid-shaped plastic cap, while the internal electronic elements (marked A to F in the cross section) are encapsulated in separate high-quality aluminum cases (modules).

A master unit with a integrated solar panel

Nearly all of the technical features to be integrated into the master unit have been discussed in the general section under Concept of the front-end.

There is only one important aspect left:

Quality assurance

The RED System´s crew has sound experience in designing sophisticated environmental monitoring stations that can operate under open skies for many years non-stop with absolutely no maintenance. It has been particularly apparent in the larger projects that the energy invested in the integration of SQA features, i.e. fully automatic test and verification procedures, always pays off in the end.

The acronym SQA stands for built-in System Quality Assurance. The proper definition of SQA features is very important, as it could save an enormous amount of money when the system reaches its final, immense dimensions, with thousands of units distributed all over the SFBA.

Which functions of the system should be regularly checked on by SQA algorithms? There are two that need special attention:

 

Sensor:

In any safeguard system, one of the most critical issues is verifying the integrity of the sensor element itself. Any malfunctioning in this key component could compromise the system´s protective value without notice.

But how can we make sure that our Argus eye has not fallen blind? Unfortunately, there is no reliable way of checking on a transducer´s function with electrical test signals only. We definitely must create real input: we must generate acceleration!

Fortunately, this is not too complicated. In the RED System, a suitable electromechanical generator will be implemented in every sensor unit. Experiments will determine whether it is better to carry out the test using a solenoid-based device or a piezo-electric actuator.

Once the sensor is equipped with this provision, a small reference signal--a click--will be applied to the sensor regularly (at an interval that can be programmed by the user). However, the evaluation of the system´s response to this stimulus is not easy.

First of all, high-frequency components will dominate in the click´s original waveform. In this case, the sensor´s signal conditioning--low-pass filtering--will reproduce the integrated waveform instead of the original signal. Furthermore, we can anticipate that the electrical signal generated during the test click will vary more or less from one sensor location to the next. Why?

This local variability is due to the fact that the sensor element itself is mechanically coupled to the sensor´s case very closely. And the case is coupled to another rigid structure (normally a wall), thus forming a tightly-coupled entity that mechanically oscillates as a whole.

Therefore, even if we could create a perfectly uniform mechanical stimulus, the observed shaking may vary from location to location depending on the different mechanical properties of the respective walls. Logically, the electrical signal generated in response to the test click will reflect the elasticity of the supporting structure behind the sensor box.

But this effect is not necessarily a disadvantage. On the contrary, it opens up the possibility of verifying the integrity of the sensor in addition to the durability of its attachment to the supporting structure! Both these aspects are likewise related to system quality. Hence, any major change in the sensor´s electrical waveform generated in response to the test click can be seen as an indicator for a problem at that specific site.

We hope that we can find suitable algorithms to verify that the sensor element is in good shape, and that the whole unit is still fixed properly in situ. One approach could be a simple comparison of the tested response function with the initial response function (directly after the installation). Any significant difference would be included in the next SOH message.

With a built-in SQA feature like this, it should be possible to diagnose different kinds of malfunction without inspecting the stations regularly. One could identify, for example, whether a sensor has been accidentally hit by a car bumper, causing the screws in its holder to become loose. This would certainly be a case for undertaking a repair. Every week or so, a list would be printed out at the network administration center proposing routes for the repair crew.

 

Battery

As explained in "Power Supply", every front-end unit is equipped with two different backup battery systems. The first level backup, the rechargeable lead acid cell, is intended for everyday service, while the second level backup, the durable lithium system, is held in reserve for problems with the life cycle of the lead acid cell.

In case of a failure in the first level backup, two different cases need to be discussed:

  • In a system intended for line power supply, a defective lead acid cell may be tolerated for a longer time because line power failure is not a frequent event in California. In case of such a rare event, the lithium system would tackle the job until a service team were scheduled for this region.
  • In a system dependent on a solar power supply, the situation would be different. The lithium cell would power the system overnight, but after a few days this cell would be dead. From this point on, the unit would stand still every night.

In order to avoid problematic conditions in the power backup system, a regular verification of the rechargeable battery´s status is necessary. This is accomplished by running the whole system solely on this rechargeable lead acid cell until the recommended lower limit of discharge voltage is reached. Simultaneously, the current consumption would be measured and integrated over time, thus providing the cell´s present capacity as another important SQA figure. This figure would be included in every SOH message and printed out in the system‘s weekly status report.

 

  5.2.2.2  
Another contribution to dialogue@red-systems.com
Robust Emergency Data Link