Description:
TECHNICAL FIELD
The present invention is related to an electronic trip unit for a circuit breaker. In particular, the present invention relates to an improved electronic trip unit for a multi-MCU (microcontroller unit) based electronic circuit breaker.

BACKGROUND
The present disclosure relates to air circuit breakers and more specifically to the electronic trip units (ETU). Modern day electronic trip units not only provide protection against various types of faults such as over/under current, voltage, frequency etc. but can also provide smart communication for (a) data sharing, (b) user interface and (c) self-healthiness check functionalities, etc. User can read as well as modify protection settings as per the load connected. Electronic trip units have the provision of (d) logging the date and timestamp of settings change and it can also (e) maintain previous settings done by the user thus providing setting change traceability. (f) Whenever fault occurs, alarm, pickup and trip log events with timestamp can be stored in the non-volatile memory of the electronic trip unit so that user can read them to trace the cause the fault. Trip log can include source of fault, settings of tripping protection, various phase currents, voltages, system frequency etc. at the time of tripping. It can also (g) store sample values of few cycles before tripping and few cycles after tripping so that the user can understand the load behavior before and after tripping. All the data mentioned above can be (h) read using the local user interface on the electronic trip unit or it can be (i) taken on mobile phone using communication such as NFC or Bluetooth. The data can also be (j) communicated to remote systems using industry communication protocols such as MODBUS, IEC61850 etc. Electronic trip units can run different self-healthiness check algorithms to make sure that components/mechanical interfaces required for breaker operation are operational. In case of any abnormality user can be pre-warned using LED indications or alarms so that timely maintenance can be scheduled. ETUs are also capable of (k) performing predictive analysis where based upon previous events stored in the non-volatile memory it can suggest the user of different causes which have created a fault in the past. This requires (l) generating and storing large amount of metering data, event logs etc. in the non-volatile memory so that analysis done is accurate.
Hence to meet above requirements, electronic trip units are designed with multiple MCU (microcontroller unit) architecture. Multiple MCU-based architecture helps in load sharing between the MCUs such that the basic functionality which is to reliably provide protection from faults is not compromised. So generally, the primary MCU runs various protection algorithms whereas other MCU/s may be responsible for running user interface, communication etc. (for example, see features (a) and (b) stated above. Event/trip logging (for example, see feature (f) above) may be done by primary MCU or by secondary MCU. In general, the primary MCU performs the event logging activity and stores the data in its internal non-volatile memory. In this case whenever secondary MCU needs to read the data (for example, see feature (h)), its read request is routed via primary MCU. This adds latency in the communication time to SCADA, i.e., Supervisory Control and Data Acquisition which includes processes and a system for gathering of data in real time from remote locations in order to control equipment and conditions. Also, if the primary MCU fails, there is no way where secondary MCU can have access to settings, event logs etc. generated by primary MCU. Another architecture approach could be where data generation and storing are handled by secondary MCU (for example, features (f), (g)). In this case, fault sensing can be done by both the MCU such that primary can run only protection algorithms and secondary MCU can sense the fault and generate event log. Otherwise, fault sensing can be done by primary MCU only and the data of fault log is shared with secondary MCU for storage. Here though the communication latency with respect to SCADA communication is reduced, there is an added burden on the communication interface between MCUs.
Hence there exists a need for improvement in this architecture where the dependency of one MCU on the other is removed and both can access the data independently. It is also required that in case of failure of one MCU, other MCU can still read the data from memory and can provide protection functionality till the user is able to take a shutdown for trip unit replacement.
In the prior art, a trip cause management device for an electric trip device is disclosed in CN104953533A. The document suggests a method to store the fault record data in a self-powered breaker with multi-MCU architecture. Architecture consists of an ASIC (application-specific integrated circuit) to perform the current and voltage measurements and to give trip command in case of a basic current fault. ASIC shares current and voltage data with MCU 2. MCU 2 performs advanced metering such as frequency, harmonics etc. on the data collected and runs advance protections. MCU 2 is also connected to non-volatile memory for saving the fault record data. It is supported by a capacitor backup which makes sure that sufficient voltage is available so that MCU 2 can do the write operations. MCU 3 is connected to MCU 2 and ASIC and is responsible for displaying the information on display. It is usually in sleep mode to reduce the power consumption and is connected to battery circuitry. This battery provides power to MCU 3 and non-volatile memory. MCU 3 can read data from non-volatile memory and display it. MCU 3 is also NFC capable and can wake up when there is no self-power using NFC.
The architecture suggested above uses two MCUs and one ASIC. It works on the principle of shared memory architecture where the data logging is done by MCU 2 and data can be read from MCU 3. The problem with this architecture is that the entire current and voltage sampling is done in ASIC and data is shared with MCU 2 and 3 for further action. In case the ASIC fails or the communication link between ASIC and MCU 2/3 fails, the electronic trip unit will fail.
Thus, there is a need for a multiple-MCU based architecture with improved shared memory which serves to function even when of one of the MCUs of the multiple-MCU fails.

SUMMARY
This summary is provided to introduce a selection of concepts in a simplified format that is further described in the detail description of the invention. This summary is not intended to identify key or essential inventive concepts of the claimed subject matter, nor is it intended for determining the scope of the claimed subject matter.
In accordance with the purposes of the invention, the present invention as embodied and broadly described herein provides solutions that overcome the problems of the prior art.
It is an object of the present invention to provide an electronic trip unit with improved shared memory architecture for redundancy.
It is an object of the present invention to enable a method of data sharing between multiple MCUs with enhanced reliability.
It is an objection of the present invention to provide an improved architecture for an electronic trip unit which consists of dual microcontroller, also referred to as two MCUs as well as the first, or the primary, controller and the second, or secondary, controller in the description, and an external non-volatile memory.
It is an object of the present invention to achieve independent access of both the MCUs to the memory contents so that even when one MCU is dead/hang and the other can provide protection. Thus, both the controllers can independently read data from the external memory irrespective of the healthiness status of the other controller. Thus, the object achieves an improved design architecture that provides redundancy and failsafe mode of operation.
According to an embodiment of the present invention, an electronic trip unit of a circuit breaker is disclosed. The electronic trip unit comprises of a primary microcontroller unit, MCU, configured to issue a first trip command to the circuit breaker upon detecting a fault, a secondary MCU configured to issue a second trip command to the circuit breaker upon detecting a fault, in case the primary MCU is in a failed state; and a shared external memory configured to be accessible to the primary MCU and the secondary MCU.
The above aspects and the advantages will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF FIGURES
To further clarify the advantages and aspects of the invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be construed as limiting its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings, which are listed below for quick reference.
Figure 1 illustrates a schematic representation of an electronic trip unit in accordance with an embodiment of the present invention.
Figure 2 illustrates a schematic representation of the architecture of dual microcontroller and shared external memory in accordance with an embodiment of the present invention.
Figure 3 illustrates a flowchart of the handshaking scheme between MCU for external memory access synchronization in accordance with an embodiment of the present invention.
Figure 4 illustrates a master and a slave architecture on the basis of the SPI communication protocol.
Figure 5 illustrates a hardware interface of primary and secondary MCU with external non-volatile memory in accordance with an embodiment of the present invention.
Figure 6 illustrates a frame format in accordance with an embodiment of the present invention.
Figure 7 illustrates an application scheme of the external memory access as per Table 1 in according to an embodiment of the present invention.
It may be noted that to the extent possible like reference numerals have been used to represent elements like drawings. Further, those of ordinary skill in the art will appreciate that the elements in the drawings are illustrated for simplicity and may not have been necessarily drawn to scale. Furthermore, one or more elements may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding of the embodiments of the invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skilled in the art having benefit of the description herein.

DETAILED DESCRIPTION
It should be understood at the outset that although illustrative implementations of the embodiments of the present invention are illustrated below, the present invention may be implemented using any number of techniques, whether currently known or in existence. The present disclosure should be in no way limited to illustrative implementations, drawings, and techniques, illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified within the scope of the appending claims along with the full scope of equivalents.
Unless otherwise defined, all terms and especially technical and/or scientific terms, used herein, may be taken to have the same meaning as commonly understood by one having an ordinarily skilled in the art.
Reference is made herein to some “embodiments”. It should be understood that an embodiment is an example of a possible implementation of any features and/or elements presented in the foregoing claims. Some embodiments have been described for the purpose of illuminating one or more potential ways in which the specific features and/or elements of the foregoing claims fulfill the requirements of uniqueness, utility, and non-obviousness.
Any particular and all details set forth herein are used in the context of some embodiments and therefore should not be necessarily taken as limiting factors to the foregoing claims. The claims and their legal equivalents can be realized in the context of the embodiments other than the ones used as illustrative examples in the description below.
An electronic trip unit of a circuit breaker is disclosed. The detailed description of the present invention is provided by way of illustrations shown in Figures 1 to Figures 6.
As schematically illustrated in Fig. 1, an electronic trip unit (ETU) 10 in accordance with the embodiments of the present invention comprises of a primary microcontroller (MCU) 20, a secondary MCU 30 and a shared external memory 40. The primary MCU and the secondary MCU are together also referred to as dual microcontroller. In the description the primary microcontroller may also be referred to as ‘the first controller’, ‘the first MCU’, or ‘one of the dual microcontrollers’ and the secondary microcontroller may also be referred to as ‘the secondary controller’, ‘the secondary MCU’, or ‘the other of the dual microcontrollers’. Also, in the description ‘the shared external memory’ may be referred to as ‘the external memory, ‘the memory’ interchangeably. According to an embodiment of the present invention, Fig. 2 illustrates a schematic architecture of the dual microcontroller and the shared external memory as implemented in an electronic circuit breaker.
In accordance with the teachings of the present disclosure, the primary MCU 20 is configured to issue a first trip command to the circuit breaker upon detecting a fault and the secondary MCU 30 is configured to issue a second trip command to the circuit breaker upon detecting a fault, in case the primary MCU is in a failed state. Further, the shared external memory 40 is configured to be accessible to the primary MCU and the secondary MCU. The embodiment is implemented based on the architecture depicted in Fig. 2. The present invention is based on an architecture with two MCUs namely the primary MCU 20 and the secondary MCU 30. Both the primary MCU 20 and the secondary MCU 30 can sense the current passing through the circuit breaker and run the protection algorithms. The primary MCU comprises of a protection unit 21 which comprises protection algorithms based on which first trip command TC is issued. Similarly, the secondary MCU comprises of a protection unit 31 which comprises protection algorithms based on which second trip command TC is issued. The primary MCU 20 as the name suggest is responsible for providing current, voltage, frequency etc. based protections, run user interface 50,generate and store event logs in fault log unit 22. The secondary MCU 30 majorly is a communication MCU comprising communication unit 32, including for example, MODBUS, IEC61850, Bluetooth, NFC, etc. and is responsible for communicating data to SCADA, mobile app etc. The secondary MCU 30 has added functionality of providing redundant protections. The secondary MCU 30 continuously senses the healthiness status of primary MCU 20. In accordance with a specific implementation, in case the primary MCU 20 fails (dead/ software hang) and fault is existing, the secondary MCU 30 issues the second trip command, TC. Thus, both MCUs 20, 30, can give command to trip, TC, to the breaker, for example, by using a flux shifter device. Fig. 2 also depicts that the primary MCU 20 provides metering data depicted by the flow ‘M’ which is accessible to the secondary MCU 30. Further, the external shared memory 40 is in serial communication with the primary MCU 20 and the secondary MCU 30, depicted by the flow ‘SC’. Moreover line 1 refers to handshaking line 1 and line 2 refers to the handshaking line 2 which is shall be explained in the foregoing description.
In order to achieve redundancy, both the MCUs, 20, 30 should always work on latest settings done by the user. Also, both the MCUs, 20, 30 should be able to access any settings, records, counters etc. irrespective of the healthiness status of other MCU. Generally, in such cases dual port external memories can be used where both MCUs can simultaneously access data. But such memories are very costly and increase burden on otherwise low-cost trip units. The architecture described in the implementation illustrated in Fig.2 is a low-cost solution. It consists of a multi-master scheme for data sharing where both the primary and the secondary MCUs 20, 30 are master and the external memory is the slave. The MCUs 20, 30 are connected to the shared external memory 40 via serial bus (SC) which can be SPI or I2C communication based. The primary and secondary MCU’s external memory access is synchronized via handshaking lines between them, see line 1 and line 2.
The external shared memory is for example, a non-volatile memory which can be a type of internal data flash memory such that it needs to be accessed via the primary MCU 20. In accordance with an implementation of the present invention, the external memory 40 is for example, an external memory such as EEPROM, FRAM or data flash which is accessible to both the primary MCU 20 as well as the secondary MCU 30. The present disclosure provides a shared memory architecture where an external memory is accessible to both the primary and the secondary MCU. The primary MCU 20 is responsible for data generating and storing whereas the secondary MCU 30 can read the data from shared memory as and when required. Thus, there is no dependency of the secondary MCU on the primary MCU for reading the data. This reduces the response time whenever data is queried from SCADA as the request for data read is not routed via the primary MCU. In case the primary MCU 20 fails, the secondary MCU 30 can still read all the event logs, protection settings etc. from the external memory 40 and communicate the same on SCADA. The architecture is shown in Fig. 2.
Fig. 3 illustrates a flowcharts depicting a flow 300A for the primary MCU 20 to access the external shared memory 40 and depicting a flow 300B for the secondary MCU 30 to access the external shared memory 40. The flows 300A, 300B illustrate the handshaking schemes between the primary MCU 20 and the secondary MCU 30 foe external memory access synchronization in accordance with the teachings of the present disclosure.
In accordance with an embodiment of the present invention, the secondary MCU 30 is configured to access the shared external memory 40 when the shared external memory 40 is not being accessed by the primary MCU 20. In accordance with another embodiment, the secondary MCU 30 is configured to access the shared external memory 40 when the primary MCU 20 has released access to the shared external memory access. If the primary MCU 20 requires access to the external memory access 40 while being accessed by the secondary MCU 30, the secondary MCU 30 is configured to release access to the shared external memory access 40. The present described embodiments are understood through the handshaking scheme particularly illustrated in flow 300B.
Amongst the two MCUs 20, 30, the primary MCU 20 is given the higher priority for accessing the external memory 40 as it is responsible for data generation. So, whenever the primary MCU 20 wants to read/write the data in the shared external memory 40, it indicates the secondary MCU 30 by setting the HANDSHAKING_LINE1. See flowchart 300A. In the first step, check if the primary controller 20 wants to access the external memory 40. If yes, in the next step it is checked if the external memory 40 is being accessed by the secondary controller 30. If the secondary controller 30 is currently accessing the external shared memory 40 and the primary controller 20 requests access in the time being, then priority is given to the primary controller 20 for data read/write, see flowchart 300B. Referring back to the flowchart 300A, when the external memory 40 is not accessed by the secondary controller or that the external memory 40 is available for access, in the next step, the primary controller 20 takes access of the external memory 40 and sets the HANDSHAKING_LINE 1, see Line 1 in Fig. 2, so as to indicate the secondary controller 30 that the external memory 40 is busy. In the next step, the primary controller 20 performs the read/write data operations from/to the external memory 40. After completion of the data read/write operation by the primary controller 20, the primary controller 20 resets the HANDSHAKING_LINE 1 to indicate the secondary controller that the external memory 40 is free.
Secondary MCU 30 needs to check the HANDSHAKING_LINE1 before initiating any read process. Referring to the flowchart 300B, in the first step it is checked if the secondary controller 30 wants to access the external memory 40. In the next step, the secondary controller 30 checks if the external memory 40 is being accessed by the primary controller 20. This is checked by checking the HANDSHAKING_LINE 1. If the HANDSHAKING_LINE1 is SET, it means that external memory 40 is being accessed by the primary MCU 20 and secondary MCU 30 needs to wait. Once the HANDSHAKING_LINE1 is RESET, the secondary controller 30 can now read the data from the external memory 40. Before initiating any read, the secondary controller 30 indicates the primary controller 20 that the external memory 40 read access is required. It does so by setting the HANDSHAKING_LINE2, see Line 2 in Fig. 2 and the next step in the flow 300B. If the primary controller 20 needs to access the external memory 40 at this time, it can respond to the secondary controller 30 by setting the HANDSHAKING_LINE1. See flowchart 300B, if HANDSHAKING_LINE1 is SET by the primary controller 20, the secondary MCU 30 resets the HANDSHAKING_LINE2 and waits till primary controller’s 20 operation is completed. If HANDSHAKING_LINE1 is not set by the primary controller 20 in response to the secondary controller’s 30 request, then the secondary controller 30 can read the data from the external memory 40 in the next step. Once the read is complete, the HANDSHAKING_LINE2 is reset by the secondary controller 30.
In accordance with the embodiments disclosed in the present application, the electronic trip unit is implemented as a multi-master architecture for data sharing where both primary and secondary MCU are master and external memory is slave. In one such implementation, the primary MCU is the first master, the secondary MCU is the second master and the shared external memory is a shared slave between the first master and the second master using a device communication protocol, which may include, for example, SPI, I2C communication protocol and alike protocols. Both primary and secondary MCUs 20, 30 are connected to the external memory 40 via serial bus which can be SPI or I2C communication based. Primary and secondary MCU’s 20, 30 external memory access is synchronized via handshaking lines between them. Fig. 3 explains the process of the handshaking scheme between the primary MCU 20 and the secondary MCU 30.
In one implementation, the device communication protocol is one of a serial peripheral interface (SPI) protocol and an inter-integrated circuit (I2C) protocol, and each of the primary MCU 20, the secondary MCU 30 and the external shared memory 40 is implemented as an integrated chip (IC), each IC including a master output slave input (MOSI) line, a master input slave output (MISO) line, a clock signal (SCLK) line and a slave select/chip select (SS/CS) pin. By way of an example, Fig. 4 illustrates a first device 400A and a second device 400B communicating via SPI in a master-slave relationship. The first device, also the master device 400A includes the primary MCU 20 or the secondary MCU 30 and the second device, also the slave device 400B, includes the shared external memory 40. Although a single master and a single slave system is illustrated to explain a simple configuration of SPI but in the context of the present invention the slave is a shared slave between two master devices. The primary MCU 20 is the first master, the secondary MCU 30 is the second master and the shared external memory 40 is a shared slave between the first master and the second master. Each of the master device and the slave device is implemented as an integrated chip (IC), each IC including a master output slave input (MOSI) line, a master input slave output (MISO) line, a clock signal (SCLK) line and a slave select/chip select (SS/CS) pin (depicted as 41, 42, 43 and 44 respectively in Fig. 4). These lines and pins implementation in the IC are known to a person skilled in the art and therefore how these are implemented is not discussed herein. For reference, it is understood that:
MOSI (Master Output/Slave Input) – Line for the master to send data to the slave.
MISO (Master Input/Slave Output)-– Line for the slave to send data to the master.
SCLK (Clock) – Line for the clock signal.
SS/CS (Slave Select/Chip Select)—Port Pin/Line for the master to select which slave to send data to.
In accordance with the present embodiment of the invention, whenever the primary MCU 20 or the secondary MCU 30 want to access the external memory 40, the chip select pin on the memory IC, for example, line 44 of the slave device 400B, is pulled LOW. In order to avoid contention by the two MCUs 20, 30, the chip select driving port pins (of the two MCUs, i.e., line 44 of the master device 400A, for both the MCUs, 20, 30 are controlled via a 2:1 mux. Similarly, the MOSI (for example, line 41 of the master device 400A in Fig. 4) and clock lines (for example, line 43 of the master device 400A in Fig. 4) of both the primary MCU 20 and the secondary MCU 30, are also selected by 2:1 mux to make sure that the state of other MCU’s MOSI line in unused condition doesn’t interfere with other MCU’s communication, referring to Fig. 5. Fig. 5 in particular illustrates hardware interface of the primary MCU 20 and the secondary MCU 30 with external non-volatile memory 40. The primary MCU 20 and the secondary MCU 30 are provided mux control lines namely Primary_Mux_Control and Secondary_Mux_Control, respectively. The primary and secondary mux control lines are XOR’d and the final output is called as Mux_control_Final, also referred as Final_Mux_Control. Depending upon the status of Mux_control_Final, the Chip select, the MOSI and the clock pins from the primary MCU 20 or the secondary MCU 30 are given the external memory’s 40 access.
According to the above described embodiment of Figs 4 and 5, in one embodiment of the present invention, the chip select pin of the external shared memory (i.e., pin 44 of slave device 400B) is set at low when being accessed or requested to be accessed by the primary MCU 20 or the secondary MCU 30.
In a further embodiment, the chip select pin of the primary MCU 20 and the chip select pin of the secondary MCU 30 (i.e., pin 44 of master device 400A) are used to select the external shared memory 40 as the slave, and the chip select pin of the primary MCU and the chip select pin of the secondary MCU are controlled using a 2:1 multiplexer (mux), referring to Fig. 5, to avoid contention between the primary MCU 20 and the secondary MCU 30, the 2:1 mux being in communication with the primary MCU and the secondary MCU via respective control lines of the 2:1 mux. The primary MCU 20 and the secondary MCU 30 are provided mux control lines namely Primary_Mux_Control and Secondary_Mux_Control, respectively which are fed as the control lines to the 2:1 mux.
In a further embodiment, the MOSI line of the of the primary MCU 20 and the MOSI line of the secondary MCU 30 (i.e., lines 41 of master device 400A) are controlled using a 2:1 multiplexer (mux) to avoid contention between the primary MCU 20 and the secondary MCU 30, the 2:1 mux being in communication with the primary MCU 20 and the secondary MCU 30 via the respective control lines of the 2:1 mux.
In a further embodiment, the SCLK line of the primary MCU 20 and the SCLK line of the secondary MCU 30 (i.e., lines 43 of master device 400A) are controlled using a 2:1 multiplexer to avoid contention between the primary MCU 20 and the secondary MCU 30, the 2:1 mux being in communication with the primary MCU and the secondary MCU via respective control lines of the 2:1 mux.
As illustrated in Fig. 5, depending upon the status of Mux_control_Final, the chip select, MOSI and clock pins from the primary MCU 20 or the secondary MCU 30 are given external memory 40 access. According to the embodiment of Fig. 5, the primary MCU is connected to a XOR operator by a primary_mux_control line which is a first control line input to the XOR operator, the secondary MCU is connected to the XOR operator by a secondary_mux_control line which is a second control line input to the XOR operator and the XOR operator is provided with a mux_control_final output line. The XOR operator is configured to perform operation on respective values of the primary_mux control line and the secondary_mux_control line to provide an output value on the mux_control_final output line, and wherein depending upon the output value, one of the primary MCU and the secondary MCU is configured to access the shared external memory. According to the embodiment of Fig. 5, depending upon the output value on the mux_control_final output line, one of the MOSI line of the of the primary MCU and the MOSI line of the secondary MCU is configured to access MOSI signal line of the shared external memory. According to the embodiment of Fig. 5, depending upon the output value on the mux_control_final output line, one of the chip select pin of the primary MCU and the chip select pin of the secondary MCU is configured to access chip select signal of the shared external memory.According to the embodiment of Fig. 5, depending upon the output value on the mux_control_final output line, one of the SCLK line of the primary MCU and the SCLK line of the secondary MCU is configured to access clock select signal of the shared external memory.
In continuation to Fig. 5, the following Table 1 shows the logic, i.e., the truth table by which the primary MCU 20 and the secondary MCU 30 take access of the external memory 40 after indicating another MCU of the same, i.e., via the handshaking lines. It is understood that when primary MCU 20 takes access of the external memory 40, the another or other MCU is the secondary MCU 30, and when the secondary MCU 30 wants to take access or takes access of the external memory 40, the another or other MCU is the primary MCU 20.

Table 1:
Sr.No Primary MCU status Primary Mux control Line Secondary MCU status Secondary Mux control Line XOR Output Memory Access
1 Healthy 0 Healthy 0 0 Secondary MCU
2 Healthy 1 Healthy 0 1 Primary MCU
3 Unhealthy 0 Healthy 0 0 Secondary MCU
4 Unhealthy 1 Healthy 1 0 Secondary MCU
5 Healthy 1 Unhealthy 0 1 Primary MCU
6 Healthy 0 Unhealthy 1 1 Primary MCU

Case 1 (Sr. No 2 – Table 1): According to a first case implementation, both the primary MCU 20 and the secondary MCU 30 are healthy. In his case, when the primary MCU is accessing the external shared memory, the primary_mux_control line is set high and the secondary_mux_control line is set low. When both the primary and secondary MCUs are healthy, the primary MCU 20 can take access of the external memory 40 by settings its Primary_Mux_Control_Line HIGH. When the primary MCU 20 is accessing the memory 40, it indicates the secondary MCU 30 of the same by setting HANDSHAKING_LINE1 HIGH. Till HANSHAKING_LINE1 is HIGH, the secondary MCU 30 will not try to access the memory 40 and will also keep its Secondary_Mux_control_Line LOW. Referring to Fig. 5, the XOR output will be HIGH in this case and the primary MCU 20 can read/write data from/to memory.
Case 2 (Sr. No 1 – Table 1): According to a second case implementation, when both the primary MCU 20 and the secondary MCU 30 are healthy and the secondary MCU 30 is requesting access to the external shared memory 40, the primary_mux_control line is set low if access is no longer required by the primary MCU 20.
In the case 2 scenario, the secondary MCU 30 wants to read data from the memory 40. Both the primary MCU 20 and the secondary MCU 30 are healthy. The secondary MCU 30 will set HANSHAKING_LINE2 HIGH to indicate the primary MCU 20 that FRAM access is needed by the secondary MCU 30. If the primary MCU 20 does not need the FRAM access, it will keep HANSHAKING_LINE1 LOW and Primary_Mux_Control_Line LOW. Since secondary_Mux_Control_Line is also LOW, referring to Fig. 5, the XOR output will be LOW in this case and the secondary MCU 30 will get access of FRAM.
Case 3: In the third case implementation, the primary MCU 20 is unhealthy and the secondary MCU 30 is healthy, i.e., the primary MCU 20 is dead or hang, the secondary MCU 30 wants FRAM access. In such case, the following two scenarios may occur as described under cases 3a and 3b:
Case 3a (Sr. No 3 – Table 1):. The primary MCU 20 is unhealthy and Primary_Mux_Control_Line is LOW. In this case, the secondary MCU 30 can access FRAM using method mentioned in case 2. Thus, when the primary MCU 20 is unhealthy and the secondary MCU 30 is healthy, the primary_mux_control line is set low and the secondary_mux_control line is set low for the secondary MCU to access the external shared memory 40.
Case 3b (Sr. No 4 – Table 1):. The primary MCU 20 is unhealthy and Primary_Mux_Control_Line is HIGH. In this case when secondary MCU 30 will try to access FRAM using method mentioned in case 2, it will not be able to read the data as primary MCU has kept Primary_Mux_Control_Line HIGH. Data read by secondary MCU 30 in such case will be 0xFFFF as the MISO lines are pulled high using 10kohm resistance. Fig 6 shows a typical frame format in which data is stored/read/written in memory. It consists of 2 bytes of start of Frame, Data and 2 bytes of CRC. Start of frame is a specific pattern (0xA5A5) which helps in easy identification of the data. Next bytes consist of actual data. Last two bytes are of checksum which are calculated from data excluding start of frame. Checksum is appended at the end of the data. During read process, checksum is computed based upon data read from memory and checksum stored with the data frame. These two checksums are compared to ensure data authenticity.
As described above for Case 3b, when checksum of data is calculated to ensure authenticity, checksum fails. The secondary MCU 30 will check the first two bytes of the frame received. Ideally the first two bytes should be of pattern (0xA5A5). If the start of frame was correctly read but checksum is unhealthy, in this case the secondary MCU 30 will understand that combination of Secondary_Mux_Control_Line used is correct and data re-read using another combination is not required. But if start of frame/pattern read is 0xFFFF, it means that actually data couldn’t be read as Primary_Mux_Control_Line is kept HIGH by the primary MCU 20. In such case the secondary MCU 30 will try to re-read the data after setting Secondary_Mux_Control_Line HIGH. Referring to Fig. 5, in this case the final XOR output will be LOW and the secondary MCU 30 will get FRAM access. In this way even when the primary MCU 20 is hang/dead, the secondary MCU 30 can read protection settings and provide protection redundancy.
The above embodiment of Case 3b is depicted vide a flowchart in Fig. 7. Fig. 7 illustrates a flowchart depicting external memory access scheme as per Table 1 described above which provides different XOR combination truth table. As illustrated in Fig. 7, when a MCU wants to read/write data in a memory and the memory is found to be not used by other MCU, the MCU will attempt to read/write data in the memory and then check the CRC for validation. If CRC is healthy, the read/write operation is successful. However, if the CRC is unhealthy, as discussed under case 3b, first the MCU attempting to perform read/write operation checks if the start of frame (SOF) pattern is 0XA5A5. If this step is determined to be yes, it is determined that the data is read/written from memory with XOR combination 1 (Sr. No 1 or 2 – Table1). Further, the data read/write operation attempted by the MCU in unsuccessful. If it is found that the SOF pattern is not 0XA5A5, it is checked if both the XOR combinations (Sr. No 1 & 4 or 2 & 6 – Table 1): have been tried. If it is determined that both the XOR combinations have been tried, the data read/write operation attempted by the MCU in unsuccessful. If it is determined that both the XOR combinations have not been tried, the MCU attempting the read/write operation tries the data read/write with XOR combination 2 (Sr. No 4 or 6 – Table 1): and follows the case 2 steps.
According to the above described embodiment of Case 3b, if the primary MCU 20 is unhealthy and the primary_mux_control line is set high, the secondary MCU 30 is configured to perform following steps to access the external shared memory:
(1) calculate checksum of data read by the secondary MCU, (2) determine if a received frame is read correctly, (3) if either of the checksum or the received frame read is incorrect, the secondary_mux_control line is set high.
Case 4: In the fourth case implementation, the secondary MCU 30 is unhealthy and the primary MCU 20 is healthy, i.e., the secondary MCU 30 is dead or hang, the primary MCU 20 wants FRAM access. In such case, the following two scenarios may occur as described under cases 4a and 4b:
Case 4a (Sr. No 5 – Table 1):. The secondary MCU 30 is unhealthy and Secondary_Mux_Control_Line is LOW. In this case, the primary MCU 20 can access FRAM using method mentioned in case 1. Thus, when the primary MCU is healthy and the secondary MCU is unhealthy, the primary_mux_control line is set high and the secondary_mux_control line is set low for the primary MCU 20 to access the external shared memory 40.
Case 4b (Sr. No 6 – Table 1):. The secondary MCU 30 is unhealthy and Secondary_Mux_Control_Line is HIGH. In this case when the primary MCU 20 will try to access FRAM using method mentioned in case 1, it will not be able to read the data as the secondary MCU has kept Secondary_Mux_Control_Line LOW. Data read by primary MCU 20 in such case will be 0xFFFF as MISO lines are pulled high using 10kohm resistance. When checksum of data is calculated to ensure authenticity, checksum fails. The primary MCU 20 will check the first two bytes of the frame received. Ideally the first two bytes should be of pattern (0xA5A5). If the start of frame was correctly read but actually checksum is unhealthy, in this case primary MCU 20 will understand that combination of Primary_Mux_Control_Line used is correct (Sr. No 2 – Table 1): and data re-read using another combination is not required. But if start of frame/pattern read is 0xFFFF, it means that actually data couldn’t be read as Secondary_Mux_Control_Line is kept HIGH by secondary MCU. In such case primary MCU 20 will try to re-read the data after setting Primary_Mux_Control_Line LOW. In this case the final XOR output will be HIGH and primary MCU 20 will get FRAM access. In this way even when secondary MCU is hang/dead, primary MCU can continue protecting the system. This scheme is illustrated in Fig. 7.
Therefore, with above mentioned architecture the dependency of one MCU on the other is removed and both can access the data independently. If any one of the MCUs fail due to any reason (hardware or firmware), the other MCU can still read the data from memory and can provide protection functionality.
The key advantages provided by the invention disclosed in the present invention include:
• The present disclosure provides a novel architecture for electronic trip unit which consists of dual microcontroller and an external non-volatile memory.
• Primary microcontroller, which is responsible for generating event logs, trip logs, oscillography data etc. is given higher priority for external memory accessing. It can both read as well as write data from/to external memory.
• Secondary microcontroller, which is primarily a communication functionality handling MCU, can read data from shared memory. It can read protection settings, metering, trip log, event log etc. independently from external memory. The read request doesn’t need to be routed via primary MCU and hence communication latency is reduced.
• Secondary MCU can also provide backup protections in case of primary MCU failure. It works on the same set of protection settings which are set by the user.
• The present disclosure provides a scheme where communication and chip select lines from primary/secondary MCU are connected to external memory using 2:1 MUX and XOR gate.
• Memory access is synchronized between MCUs depending upon status of HANDSHAKING_LINE1 and HANDSHAKING_LINE2. HANDSHAKING_LINE1 is output from primary MCU and input to secondary MCU. HANDSHAKING_LINE2 is output from secondary MCU and input to primary MCU. HANDSHAKING_LINE1 is SET by primary MCU to indicate secondary MCU that external memory access is required. Similarly, secondary MCU SETs HANDSHAKING_LINE2 when it requires memory access.
• Primary and secondary MCU are also provided with Primary_Mux_Control and Secondary_Mux_Control line. Primary_Mux_Control and Secondary_Mux_Control lines are XOR’d and output is named Final_Mux_Control. Based upon the status of Final_Mux_Control, either of primary/secondary MCU will get memory access.
• Thus, the present disclosure provides an architecture where the status of communication lines of one MCU doesn’t affect communication capability of another MCU. Both MCUs can independently access memory contents even when other MCU is dead/hang and can provide protection.
, Claims:1. An electronic trip unit of a circuit breaker comprising:
a primary microcontroller unit, MCU, configured to issue a first trip command to the circuit breaker upon detecting a fault;
a secondary MCU configured to issue a second trip command to the circuit breaker upon detecting a fault, in case the primary MCU is in a failed state; and
a shared external memory configured to be accessible to the primary MCU and the secondary MCU.

2. The electronic trip unit as claimed in claim 1 wherein the secondary MCU is configured to access the shared external memory when the shared external memory is not being accessed by the primary MCU.

3. The electronic trip unit as claimed in claim 1 wherein the secondary MCU is configured to access the shared external memory when the primary MCU has released access to the shared external memory access.

4. The electronic trip unit as claimed in claim 2 or 3 wherein the secondary MCU is configured to release access to the shared external memory access if the primary MCU requires access to the external memory access while being accessed by the secondary MCU.

5. The electronic trip unit as claimed in any of the preceding claims wherein:
the primary MCU, the secondary MCU and the shared external memory form a multi-master architecture;
the primary MCU is the first master, the secondary MCU is the second master and the shared external memory is a shared slave between the first master and the second master using a device communication protocol.

6. The electronic trip unit as claimed in claim 5 wherein the device communication protocol is one of a serial peripheral interface (SPI) protocol and an inter-integrated circuit (I2C) protocol, and each of the primary MCU, the secondary MCU and the external shared memory is implemented as an integrated chip (IC), each IC including a master output slave input (MOSI) line, a master input slave output (MISO) line, a clock signal (SCLK) line and a slave select/chip select (SS/CS) pin;
Wherein:
the chip select pin of the external shared memory is set at low when being accessed or requested to be accessed by the primary MCU or the secondary MCU;
the chip select pin of the primary MCU and the chip select pin of the secondary MCU are used to select the external shared memory as the slave, and the chip select pin of the primary MCU and the chip select pin of the secondary MCU are controlled using a 2:1 multiplexer (mux) to avoid contention between the primary MCU and the secondary MCU, the 2:1 mux being in communication with the primary MCU and the secondary MCU via respective control lines of the 2:1 mux.

7. The electronic trip unit as claimed in claim 6 wherein the MOSI line of the of the primary MCU and the MOSI line of the secondary MCU are controlled using a 2:1 multiplexer (mux) to avoid contention between the primary MCU and the secondary MCU, the 2:1 mux being in communication with the primary MCU and the secondary MCU via respective control lines of the 2:1 mux; and/or
the SCLK line of the primary MCU and the SCLK line of the secondary MCU are controlled using a 2:1 multiplexer to avoid contention between the primary MCU and the secondary MCU, the 2:1 mux being in communication with the primary MCU and the secondary MCU via respective control lines of the 2:1 mux.

8. The electronic trip unit as claimed in claim 6 or 7 wherein:
the primary MCU is connected to a XOR operator by a primary_mux_control line which is a first control line input to the XOR operator;
the secondary MCU is connected to the XOR operator by a secondary_mux_control line which is a second control line input to the XOR operator;
the XOR operator is provided with a mux_control_final output line, wherein the XOR operator is configured to performs operation on respective values of the primary_mux control line and the secondary_mux_control line to provide an output value on the mux_control_final output line, and
wherein depending upon the output value, one of the primary MCU and the secondary MCU is configured to access the shared external memory.

9. The electronic trip unit as claimed in claim 8 wherein depending upon the output value on the mux_control_final output line, one of the MOSI line of the of the primary MCU and the MOSI line of the secondary MCU is configured to access MOSI signal line of the shared external memory.

10. The electronic trip unit as claimed in claim 8 wherein depending upon the output value on the mux_control_final output line, one of the chip select pin of the primary MCU and the chip select pin of the secondary MCU is configured to access chip select signal of the shared external memory.

11. The electronic trip unit as claimed in claim 8 wherein depending upon the output value on the mux_control_final output line, one of the SCLK line of the primary MCU and the SCLK line of the secondary MCU is configured to access clock select signal of the shared external memory.

12. The electronic trip unit as claimed in claim 8 wherein both the primary MCU and the secondary MCU are healthy, the primary_mux_control line is set high and the secondary_mux_control line is set low when the primary MCU is accessing the external shared memory.

13. The electronic trip unit as claimed in claim 12 wherein when the secondary MCU is requesting access to the external shared memory, the primary_mux_control line is set low if access is no longer required by the primary MCU.

14. The electronic trip unit as claimed in claim 8 wherein the primary MCU is unhealthy and the secondary MCU is healthy, the primary_mux_control line is set low and the secondary_mux_control line is set low for the secondary MCU to access the external shared memory.

15. The electronic trip unit as claimed in claim 14, wherein if the primary MCU is unhealthy and the primary_mux_control line is set high, the secondary MCU is configured to perform following steps to access the external shared memory:
• calculate checksum of data read by the secondary MCU;
• determine if a received frame is read correctly;
• if either of the checksum or the received frame read is incorrect, the secondary_mux_control line is set high.

16. The electronic trip unit as claimed in claim 8 wherein the primary MCU is healthy and the secondary MCU is unhealthy, the primary_mux_control line is set high and the secondary_mux_control line is set low for the primary MCU to access the external shared memory.

17. The electronic trip unit as claimed in claim 16, wherein if the secondary MCU is unhealthy and the secondary_mux_control line is set high, the primary MCU is configured to perform following steps to access the external shared memory:
• calculate checksum of data read by the primary MCU;
• determine if a received frame is read correctly;
• if either of the checksum or the received frame read is incorrect, the primary _mux_control line is set low.