In order to reduce data traffic in a network, a master node sends master data to at least one checking instance. The master data are checked by the checking instance. In the absence of errors, either the master data or slave data determined by the slave node are sent by the checking instance to the data-processing unit. When an error is recognized, all master data and slave data available at the checking instance are sent by the checking instance to the data-processing unit.

In order to provide simple, fast, and reliable verification of the functioning and processing of an automation task in the form of software in a multi-channel safety-oriented automation component (1), the software (SW1) is run in one channel (K1) of the automation component (1) in an active unit (P1) of the hardware of the channel (K1), and first diversity software (SW3) redundant relative to the software (SW1) is run in a verification unit (V1) in this channel (K1), wherein in a processing step (Z1) input data (E.sub.z) associated with the software (SW1) and first output data (A.sub.z) computed by the software (SW1) in this processing step (Z1) are temporarily stored in a memory unit (M1), and the diversity software (SW3) in the verification unit (V1) computes second output data (A.sub.z) based on the stored input data (E.sub.z) independently of the processing of the software (SW1) in the active unit (P1), and the second output data (A.sub.z) computed by the diversity software (SW3) is compared with the stored first output data (A.sub.z) of the software (SW1) in order to verify the processing.

A system includes a safety relevant component that generates a data packet in response to receiving a request to perform a task and that communicates the data packet. The system further includes a first fail-safe chassis (FSC) that continuously generates a first chassis health signal, that determines whether the data packet is valid, and that selectively determines whether to de-assert the first chassis health signal based on the determination. The system also includes a second FSC that continuously generates a second chassis health signal, that determines whether a copy of the data packet is valid, and that selectively determines whether to de-assert the second chassis health signal based on the determination. The system further includes a safety relay box module that determines whether to instruct the first FSC to operate in a predetermined mode based on the first chassis health signal and the second chassis health signal.

A controller module (CM) includes buffers that feed back signals output using respective signal lines used for mutual communication with other CM, and a first detecting unit and a second detecting unit that detect abnormality such that the levels of the signals output using the signal lines do not change from respective specific levels when each level of the fed-back signals does not coincide with an expected level being a level previously determined according to a predetermined timing.

An integrated fail-silence and fail-operational control system includes a primary controller controlling features of devices while operating under non-fault operating conditions. A secondary controller includes a fail detector/decider module monitoring faults in the primary controller. The fail detector/decider module determines whether the fault in the primary controller is associated with a fail-silence requirement or a fail-operational requirement. If the fail detector/decider module determines the fault is a fail-silence requirement, then the fail detector/decider module actuates a shutdown command to the primary controller to shut down a feature affected by the fault where the feature becomes non-operational. If the fail detector/decider module determines that the feature associated with the fault is a fail-operational requirement, then the fail detector/decider module signals the primary controller to relinquish controls of the feature to the secondary controller. The secondary controller functions as a high assurance system for controlling the feature in a fail-operational mode.

An information processing system includes a first determining unit, a second determining unit, and a processing unit. The first determining unit determines a result indicating a second fixed state for data when a first condition is satisfied, the first condition indicating that t2 or more results of a first recommended state or a first fixed state are selected for the same data. The second determining unit determines the result indicating the first fixed state for the data when a second condition is satisfied, the second condition indicating that ti or more results indicating the second fixed state are selected for the same data. The second determining unit also determines the result indicating the first recommended state for the data when a third condition is satisfied, the third condition indicating that (b+1) or more results indicating the second fixed state are selected for the same data.

A data processing apparatus is provided. Determination circuitry performs a determination of a vulnerability of each of a plurality of functional circuits in a processing circuit and modification circuitry modifies a behaviour of a reprogrammable circuit to match an architectural behaviour of a vulnerable functional circuit in the functional circuits in response to the determination.

A battery pack includes a current detector configured to detect a charging current to secondary battery, a drive circuit configured to drives a charge switch based on the charging current detected by the current detector, a charge controller configured to control operation of the charge switch by the drive circuit, a monitoring unit configured to monitor operation of charge controller, and a judging unit configured to instruct, based on the charge controller and the monitoring unit, the charge switch to be able to or unable to operate.

A system and method for integrity monitoring on a heterogeneous system-on-a-chip (SoC) processing environment provides sets of dynamic input data to integrity applications running on one or more application cores (e.g., where safety critical applications are hosted) which generate an integrity output according to function/instruction sets. The dynamic input data is also provided to an integrity monitor running on a dissimilar integrity core (e.g., different architecture and/or other core type than the application cores) which receives the integrity output from the application cores and generates its own integrity result based on the same function sets and the same dynamic input data. The integrity monitor compares the local integrity result to the integrity outputs received from the application cores. If the integrity outputs deviate from the integrity result, the integrity core initiates a fault response, which may include resetting the deviant application core, all application cores, or the full SoC environment.