.. _fsd304: FSD304: System architecture description ####################################### .. list-table:: Header :header-rows: 0 * - Title - FSD304: System architecture description * - Products - Safety Simplifier * - Requirements - 61508-2:2010 7.4.2.2 * - Purpose - Describe the E/E/PE system architecture * - Input - E/E/PE system safety requirements * - Output - E/E/PE system architecture description Table of contents ***************** .. contents:: .. todo: Refer here from software safety requirements specification. Block diagram overall EEPE System --------------------------------- From EN 61508:2010 perspective, a safety function can only be implemented in a complete E/E/PE safety-related system which includes the elements sensor, logic and actuator. The safety functions are general, as the Simplifier is a PLC. A summary of the different types is covered in FSD115. Note that Logic can consists of several Simplifier units that are talking with each other through radio and/or CAN communication. Subsystems ---------- From FSD120, 7.2.3.2, the following subsystems are described: Power supply ^^^^^^^^^^^^ The power supply fulfills power requirements, ie DC power up to 33V. It is a standard step-down converter, but also generates negative help voltage for analogue switchers, and higher voltages to help turn on N-FET transistors. The DC/DC is current mode controlled, automatically making it short-circuit protected. Over voltage devices are use too. After the +5V, the critical PSU for the CPUs are redundant. Both CPUs measure and supervises the voltages and takes action if errors are detected. **HW fault tolerance: 0 for first step, 1 for CPU power.** Inputs ^^^^^^ The inputs (which are shared with transistor outputs), are mainly comprised of two resistor dividers, where each CPU measures one of the divided voltages. To be able to detect short-circuit between measurement points, the resistor dividers have different values for each CPU. To be able to differentiate between an output transistor broken in short-circuit, and external voltage (regular input), when an output transistor is on, another transistor pulls one of the resistor divider voltages towards ground via a resistor, so the difference can be measured. As so many signals are measured (2*14), four analogue multiplexers (74HC4051, two for each CPU) are used to multiplex inputs. Both CPUs measure two inputs each time. The main CPU controls the three selector signals for all multiplexers, and the second CPU measures the selector signals and verifies that the correct selection is made. Also, to improve signal quality, voltage follower OPamps are used. **HW fault tolerance: 1** Logics, excluding communication ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The main logic is handled by two CPUs clocked by the same crystal for to guarantee no slipping or delays. To increase diversity and to reduce common cause errors, two different CPU models are used, and unique software for each CPU. Besides numerous diagnostics performed by the CPUs, the general functionality is to: #. measure input signals, #. make logic according to configurations, #. control outputs. CPU1 (the larger), controls the outputs by directly controlling the output transistors. CPU2 (the smaller), makes the same calculations, but just measures that the outputs are correct. If there is a mismatch, safe state is entered, which, among other things, turns off the main power to all outputs. All simple and complex input and output types are purely handled by software. Those are: * digital input * digital output * OSSD output * A/B/C/D/E-pulse output * A/B/C/D/E-pulse input * Voltage window comparator This means that the CPUs handle inputs as purely analogue signals, then perform preconditioniong, filtering and pattern matching in SW. Besides direct signal measuring between CPUs (mainly for diagnostics), there is also a CPU-to-CPU communication channel. This is a normal full duplex UART, operating at high baudrate (>500kbps). The high baudrate is required to exchange the large amount of data required by the CPUs each tick, which is 1ms. One critical thing communicated over the CPU-to-CPU channel is received (radio/CAN) communication data. Only CPU1 is physically connected to the communication interfaces. After reception it forwards packets directly to CPU2 over UART as black channel. For transmission, the checksums for all packets sent by CPU1 are seeded by CPU2. This ensures that both CPUs must agree about what data to send for the CRC to be ok. For logic calculations, there are two important interrupts that covers it. #. Fast interrupt (fast tick or ftick), running at 16kHz. This interrupt mainly handles low level input processing, radio/CAN communication, CPU2CPU communication, and some output handling. As input goes through muxes, every I/O is sampled at 2kHz (2 I/O at a time). This is enough for first level precondititioning and filtering. Pattern matching is also handled here. #. Main tick (tick) interrupt running at 1kHz. This is where the actual logic is calculated. Thus, all timing is always in 1ms resolution. This design gives a very reproducible and deterministic functionality. Either the units can handle all calculations every 1 ms, or it fails totally - not time slipping or delays are allowed. There are special DREQs and internal verifications that uses HW timers to make sure that the interrupts are not ever missed or delayed. If they are, safe state is entered. **HW fault tolerance: 1** Radio communication ^^^^^^^^^^^^^^^^^^^ As stated in FSD120, radio is handled as a black channel (see FSD301). The HW is comprised of a separate module (PCB023). Main component is a TI CC2520 radio chip, that handled 802.15.4 low power communication. A proprierity protocol implemented in a subset of 802.15.4 is used to send out data. To improve radio coverage, different nodes resend (repeats) data from other nodes. Safety data is 16 bits per node for radio communication (16 memory cells). See system requirements. The safety CRC of all radio packets sent by CPU1 is first seeded by a CRC calculated by CPU2. If the CPUs disagree about what data to send out, the CRC will become corrupt and all receiving nodes will not be able to calculate the CRC. If there is an error detected in CPU2, it has the possibility to turn of radio completely. **HW fault tolerance: 1** CAN communication ^^^^^^^^^^^^^^^^^ CAN peripheral unit is integrated in the GD CPU. Safety data is sent out as is. CAN has more bandwidth, thus extra 16 CAN memories are sent from every node in addition to the radio memories. CAN is a much more reliable communication method, thus repeating is not supported here. Just like radio, all packets have checksums seeded from CPU2. If there is an error detected in CPU2, it has the possibility to turn off CAN completely by pulling CAN-TX high. **HW fault tolerance: 1** Transistor outputs ^^^^^^^^^^^^^^^^^^ Transistor outputs are made by a main over-dimensioned transistor that enabled output for all 14 outputs, and then individual transistor output for every output. For a safety function to reach CAT4 (13849), two or more outputs can be combined. The final output switch for every output is made by two opposite direction in series connected N-FETs. This reduces power consumption (no diode drop), and also protects the output stage if input voltage is higher than power voltage. The input part of the I/O is reused for outputs, for diagnostics. **HW fault tolerance: 1** Relay outputs ^^^^^^^^^^^^^ Each relay output is comprised of two 2-terminal relays (CO & NO). The CO/NC is used to short-circuit a transformer. A several 100kHz square-wave is sent through this transformer. Thus, it can be sensed if the wiper inside the relays really moves. **HW fault tolerance: 1** Hardware architecture --------------------- For more detailed description of hardware architecture, see electrical schematics (mainly PCB018) and design models (hardware block diagrams). Software architecture --------------------- For description of software architecture, see source code and design models. Specific EN 61508 details ------------------------- .. motivation:: HW/SW interactions :id: MOTIVATION_304_100 :tags: fsd304 :status: PASS As described in module specification above, most advanced processing is made by software, including pattern matching, digital filtering etc. The HW handles the basic interface to give raw data into the CPUs. For further details, see the module above. .. motivation:: Design subsystems :id: MOTIVATION_304_101 :tags: fsd304 :status: PASS The system is decompsed into subsystems, as described above. Each subsystem is specified. Integration tests are specified in :ref:`FSD150` and :ref:`FSD300`. .. motivation:: De-rating :id: MOTIVATION_304_103 :tags: fsd304 :status: PASS The main transistor to cut the power (F3, Alpha&Omega AO4421) is rated for 6.2A, while the specification for the simplifier is maximum 2A. The same is for the relays, they arere specified for 6A operation, while only 2A is specified for the simplifier. The main step down converter (LM5085) in the power supply is rated for 4.5V-75V DC, while the simplifier is rated for 7V-33V DC. Safe state is entered if the voltage is outside the range 7V-33V (see :need:`DREQ_24D`). Output transistors (FDS89161LZ) are rated for 100V 2,7A, while Simplifier outputs are rated for up to 33V 2A. See PCB018K hardware schematics for details. .. motivation:: Hardware design methodology :id: MOTIVATION_304_102 :tags: fsd304 :status: PASS a) The hardware design fulfills the requirements including modularity, transparency. Furthermore, it is simple - especially as it is very general and all higher computations are made in software. Furthermore, many man-years experience from similar designs is re-used. b) The requirements are fulfilled in the module documentation above. c) Documentation according to EN 61508:2010, CAD-files, technical manual, component lists and reviews. d) The validation tests are taken into account during the design work. All validation tests can be performed without any modifications of the test object. Common test equipment shall be used. For validation and verification details, see the documents E/E/PE system safety validation planning. When the products have been produced, test software is used to verify the overall functions of the units before being shipped. The test software tests e.g. the radio module and the safety CPUs. Pass/fail criteria is implemented in the test software. .. todo: This test software should be described somewhere. L2/L3 tools? EN 61508-2, 7.4.9.4m ^^^^^^^^^^^^^^^^^^^^ See module description above for hardware fault tolerances. EN 61508-3, 7.4.5.3 ^^^^^^^^^^^^^^^^^^^ The design is modular, testable and has capacity for safe modifications. The module descriptions, software block diagram, internal tests prove this. Revision History **************** .. list-table:: :header-rows: 1 * - Date - By - Version - Description * - 2018-04-16 - Jesper Ribbe - V1 - Initial version * - 2018-07-31 - Jesper Ribbe - V2 - First version to cover most needed parts. * - 2023-08-15 - William Forsdal - V3 - * Rewrite to reStructuredText and restructure for new FSA documentation structure. * Clarify input multiplexers, update for new hardware. * Update radio and CAN subsystems to seed packets from CPU2 instead of CPU2 monitoring. * General clarifications.