EZIS TECHNOLOGY

Restoring information even in noise,
and deciding whether it is valid.

EZIS addresses the delivery path of sensor and communication information. Instead of passing a received signal through as is, it is designed to decide whether the information is valid and, based on that decision, to restore it, hold it, or exclude it from the output.

01 / THE PROBLEM

Even when sensing is correct, the delivery path needs its own scrutiny.

Information measured by a sensor travels through a link to data acquisition units and control systems. If noise and interference affect this path, information that differs from the original measurement can be passed on to the next stage.

The problem is not only that noise exists. If corrupted information is accepted as normal input, it can affect analysis results and equipment decisions. EZIS addresses the reliability of this delivery path.

Conceptual diagram of a sensor measurement corrupted by noise and delivered as altered input
Conceptual diagram of a delivery error. It is not a measurement result from any specific customer site. · Click the image to enlarge.

02 / DIFFERENT ROLES

Reducing noise and judging information are different roles.

Shielding, grounding and filtering are important protective measures that reduce interference coupling and unwanted signal components. Error detection checks for changes in information within a defined check coverage.

However, if a value was corrupted before the check information was generated, subsequent checks may not be able to detect that change. EZIS is being developed to work alongside existing protective measures, addressing whether the delivered information is valid.

Conceptual diagram comparing the roles of shielding and filtering, transmission error checking, and system-level decisions
Conceptual diagram of a typical sensing path. Actual protection points and check coverage differ by equipment. · Click the image to enlarge.
RolePrimary problem addressedPoints to review together with EZIS
Shielding, grounding, filteringSuppressing interference coupling and unwanted signal componentsEffect of residual disturbance on reception results
Error detectionDetecting errors based on check information and rulesCheck coverage and where check information is generated
by SOOMBEESDecision on and restoration of information in the transmit/receive processDecision conditions, output policy, interfacing with customer equipment

03 / RESTORE & REGENERATE

Restored information, as a newly generated output signal.

01

Transmit/receive link

The transmitter that sends information and the receiver that accepts it are configured together. The roles of restoring the original information and judging the reception result are placed within the link.

02

Information restoration

The receiver examines whether information can be confirmed from a noisy received signal. When the conditions are met, the restored information is passed on for downstream systems to use.

03

Signal regeneration

An output signal is newly generated from information decided as valid. This is distinct from passing the received waveform straight through.

InputDelivered signal

A segment that may be affected by noise and interference

EZIS receiverDecision · restoration

Output path separated according to validity

If validSignal regeneration

New output generated from the restored information

Conceptual explanation from the customer's functional perspective. It does not include the internal encoding scheme, observation structure or decision conditions.

04 / THREE STATES

When it is not certain, it is not confirmed.

Reception results are handled as valid, hold or invalid. Rather than simply outputting a single value, the core function is to indicate how each result should be treated.

01 / VALID

Valid

Restore and deliver the information

The result satisfies the defined decision conditions. Valid information is designed to be restored, regenerated and passed to the next stage.

02 / HOLD

Hold

Secure an opportunity to re-check

The state cannot be confirmed from the current result alone. We are evaluating flows that re-check through repeated observation or retransmission.

03 / UNDEFINED

Invalid

Excluded from normal output

The result cannot be used as valid information. It is distinguished from normal results so that downstream equipment can respond according to the state.

Whether to retain the previous value, re-check, or stop the equipment in the hold or invalid state is determined by the operational requirements of the customer's system.

05 / RECOVERY

We also verify normal reception after a temporary disturbance.

Re-check and state recovery

When new information is received after an interval that was difficult to decide, the result is decided again. Evaluation covers not only whether normal information is restored, but also how long hold and invalid states persist and whether normal reception resumes.

Evaluation suited to application conditions

  • Is information delivered accurately under normal input?
  • Under disturbed input, is incorrect information accepted as valid?
  • Are uncertain results classified as hold or invalid?
  • Does the link return to normal reception after the disturbance ends?

06 / HARDWARE

The core decision function is implemented in hardware.

So that customer software
does not have to run the EZIS internal decision computation
itself.

The core observation, decision and restoration functions are implemented as circuits. Downstream software can use the EZIS decision results and output states in line with the system's operating policy.

This does not mean that the link method and state handling of existing equipment are automatically compatible. Power, I/O, response requirements and the scope of software integration are confirmed for each application environment.

07 / CUSTOMER VALUE

The value we aim to verify on customer equipment

01

More usable information

The goal is to make use of information that can be restored in noisy environments, while identifying uncertain results.

02

Containing the propagation of erroneous information

Decision logic and output policy are evaluated together to reduce the risk of incorrect input carrying over into subsequent analysis and control.

03

Separating the decision computation

We aim for an architecture that keeps the core decision in hardware and clearly defines the role of customer software and the scope of integration.

08 / DEVELOPMENT & EVALUATION

We distinguish what has been verified from what must be confirmed in the field.

Development is under way using models/simulation and FPGA boards. Applying the technology to customer equipment requires separate evaluation under actual input, wiring and disturbance conditions.

Development verification

Model and circuit behavior

Functions are confirmed by comparing decision and output results for the same input.

Field evaluation

Equipment conditions and link

Results are evaluated against signal characteristics, installation environment, disturbance and response requirements.

Productization

Reproducibility and operating conditions

Specifications are refined by confirming repeatability, environmental variation, equipment-to-equipment variation and output policy.

This page does not guarantee error blocking under all disturbances, field performance, or completed certification or mass production. Applicability is evaluated including the conditions under which decisions change and the remaining constraints.