A Coremicro Reconfigurable Embedded Smart Sensor Node has the capability of hosting intelligent algorithms to support health monitoring applications and has optional standardized software communications stack. The purpose of this present invention is to provide a flexible low power distributed computational platform to deploy intelligent software elements (based on Artificial Intelligence techniques) among the system architecture to result in a reconfigurable scheme for distributed intelligence granularity. This invention is able to be applied to a wide variety of monitoring applications either as a Standalone Smart Sensor (SSS, i.e. single Smart Sensor Node) or as a modular and scalable Smart Sensor Network configuration. Therefore, the CRE-SSN is ultra-low in power consumption, has optional pattern recognition through Artificial Neural Network, physical communication layer reconfigurable capability, has scalable communications capability, and low in weight, and optimized in size. An optional IEEE 1451 software stack is provided to manage sensors via set of standardized commands.

BACKGROUND OF THE PRESENT INVENTION

1. Field of Invention

The present invention relates to a hardware implementation of Smart Sensor optimized for size, weight, and power consumption (SWaP). In health monitoring applications, in order to optimize data-acquisition and diagnostics capabilities, it is desirable that systems are capable of performing intelligent health monitoring functions (such as self-diagnostics, self-healing, calibration, and sensor data validation) to enhance system reliability and performance. Considering critical systems, it is important to embed intelligence in elements, components, subsystems, and systems within standardized frameworks. Then, in this type of applications, distributed Smart Sensor Networks provides a strategy for working with these technological challenges.

Accordingly, efficient schemes which enable fully customization (when tailoring the system to specifications) and have reconfigurable capability (once being installed) are desired features in this present invention. Especially in the aerospace industry, the above mentioned advanced technology is highly desired. The CRE-SSN provides these capabilities (where additional capabilities can be selectedly deployed in the present invention) and expands the foundation for integrating the intelligent algorithms, so as to conduct health monitoring functions within an optional standardized framework based on IEEE 1451.0 (Dot0). However, comparing with many commercial sensors on the markets, the presented invention has the better function for collecting raw data and providing version of the Dot0 stack (most of the available versions on the market only include the basic Transducer Electronic Data Sheets (TEDS) capability).

According to the strategic infrastructure of the commercial and military fields, capabilities, which have advanced sensors, data-acquisition systems, preprocessing algorithms, and diagnostics mechanisms, are required to determine the condition of the automated logistic systems. In order to achieve the above mentioned capabilities, following the Condition Based Maintenance (CBM) policies is an optimal way to establish this system. Therefore, automated logistic system is built upon CBM. In addition, an implementation strategy within the automated logistic system is based on Condition Based Maintenance Plus (CBM+) policies which comprise health monitoring, logistics, and configuration management. In other words, it can be predictable that CBM and CBM+ policies are required to combine together to support the supply chain. All these technologies are require in their architecture‘s lower layer, especially for the monitoring capability, smart sensors with self-identification capability is a meaningful way to benefit the overall system performance, and provide a strategy to optimize system readiness.

This invention focused on a technology which can be implemented in the low-level layer of such kind of system. The CRE-SSN has the configurable Smart Sensor functions and is designed to support a sophisticated and standardized health diagnostics system.

2. Description of Related Arts

Important advances of Smart Sensors and Networks have been achieved. For example, a lot of attention has been given to optimizing wireless communication interfaces, such as routing algorithms, recovering schemes, and the reduction of power consumption. Also, in current small size military applications, ultra-low power and low weight sensors are required for monitoring systems. And, for the corrosion monitoring, leakage detection in critical systems (such as hydraulic systems in avionics or fuel lines), and health detection for rotorcraft airframes structure, the ultra-low power and low weight sensors are required also. Accordingly, in some relevant application fields, it is important to improve sensor technologies under extreme operation conditions. The common improvements need to be achieved among these applications are: (a) design for optimizing SWaP; (b) enhancing sensor intelligence to perform health monitoring functions (system diagnostics, sensor self-diagnostics, data validation, self-healing, and calibration); (c) design for supporting the configuration management (self-identification); and (d) standardization. The CRE-SSN invention offers a set of configuration features to support these improvements.

SUMMARY OF THE PRESENT INVENTION

A main object of the present invention is to provide a reconfigurable embedded smart sensor node capable of providing in a scalable way: (a) data acquisition capability; (b) computational power to embed preprocessing algorithms (extract features from raw data); (c) sensor self-diagnostics (for local or within the network supervisor device); (d) failure detection by Artificial Intelligence techniques; (e) self-identification; (f) in compliance with IEEE 1451. These baseline capabilities are scalable and customizable while subsets of such features can be selected for embedding within the present invention.

Another object of the present invention is to provide a reconfigurable embedded smart sensor node for achieving reconfiguration, wherein the reconfigurable embedded smart sensor node is interfacing with communication modules through serial communication profile, and is able to switch different communication modules (and then enabling infusion of different wireless communication standards) without affecting the CRE-SSN‘s Dot0 communication protocol. A Zigbee module is provided the baseline for interfacing within the networks (although any device with serial communication profile is a valid interface for its infusion within the sensor).

Another object of the present invention is to provide a reconfigurable embedded smart sensor node which is able to optimize the flexibility and the reconfiguration so as to enable handling different types of transducer (actuator or sensing elements, where this last is termed "sensor" according to the present invention). In particular, The CRE-SSN‘s sensors can be set as single sensor (i.e. only a single sensing element attached to the CRE-SSN) or sensor suite configuration (i.e. sets of homogeneous or heterogeneous sensors).

Another object of the present invention is to provide a reconfigurable embedded smart sensor node which is to embed Artificial Neural Networks that can be retrained in a central node (or host computer) and transferred to CRE-SSN through the IEEE 1451 communication protocol.

Another object of the present invention is to provide a reconfigurable embedded smart sensor which comprises a Standalone Smart Sensor (SSS) capable of hosting transducer sets (i.e. sensor suites), wherein the number of transducer sets is ≦7 (for a given set realization) and it is able to accommodate diversity of sensor types, such as homogeneous or heterogeneous type sensor suites.

Another object of the present invention is to provide a reconfigurable embedded smart sensor which comprises a Smart Sensor Network by interconnection of sets of CRE-SSN to a host computer.

Another object of the present invention is to provide a reconfigurable embedded smart sensor which comprises a distributed hardware platform capable of hosting intelligent software elements based on Artificial Neural Network.

Another object of the present invention is to provide a reconfigurable embedded smart sensor which comprises an optional standardized software communications stack to manage the internal resources, sensor suite, actuators, and Intelligent Software Elements in the CRE-SSN.

Another object of the present invention is to provide a reconfigurable embedded smart sensor which has optimized size, weight, and power (SWaP).

Another object of the present invention is to provide a reconfigurable embedded smart sensor which comprises a swappable physical communication channel in the communication software stack to enable wireless communication through different wireless standards.

Accordingly, in order to achieve the above mentioned objects, a reconfigurable embedded smart sensor node, comprising:

• a communication module, a processing unit using an ultra-low-power microcontroller and complementary resources including a reconfigurable RS-232 serial port wired interface, a power management unit, and JTAG port?35;
• a rich set of software resources to implement the functionalities of Network Capable Application Processor (NCAP) and Transducer Interface Module (TIM); and
• a two-board stack consisting of a main board hosting digital cores; and an expansion board having a customizable signal conditioning, a plurality of sensor suite connections, an expansion bus and a communication module for baseline implementation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The following description is disclosed to enable any person skilled in the art to make and use the present invention. Preferred embodiments are provided in the following description only as examples and modifications will be apparent to those skilled in the art. The general principles defined in the following description would be applied to other embodiments, alternatives, modifications, equivalents, and applications without departing from the spirit and scope of the present invention.

Referring to?FIG. 1?to?FIG. 3?of the drawings, a CRE-SSN?10?is provided according to a preferred embodiment of the present invention, wherein the CRE-SSN architecture?10?is comprised of cutting edge technologies that utilize state-of-the-art standards for a Smart Sensor realization that can perform the function of a Transducer Interface Module (TIM) and Wireless Transducer Interface Module (WTIM) as defined by the IEEE 1451.0 standard. The CRE-SSN?10?is designed to comply with IEEE 1451.0 (Dot0) for providing data acquisition, self-identification, calibration, and sensor management scheme. In such manner, architecture implementation of smart networks is enabled by providing (a) a standardized framework comprised of a rich set of software resources to implement the functionalities of Network Capable Application Processor (NCAP)?50?and a communication software stack, which is embedded as Transducer Interface Module?60?(sets) in the present invention; and (b) a CRE-SSN?10?consisting by flexible and miniaturized sensors on main sensor board?100and expansion board?200?(two board stack, as baseline). To optimize throughput, the CRE-SSN?10?design is based on two devices: (1) a communication module?30?and (2) a processing unit using an ultra-low power microcontroller?36?as depicted in?FIG. 1. Complementary resources include: (a) reconfigurable RS-232 serial port wired interface?34; (b) power management unit?33; and (c) JTAG port?35. The CRE-SSN architecture?10?allows swapping two sensor suites,?40?and?41, with the baseline?20?for system reconfiguration. Sets of sensors suites?21,?42, and?43, can be formed by same or different transducer type and up to seven sensors can be controlled through the expansion board?200?in the baseline?20?of the CRE-SSN implementation. Then sets of homogeneous or heterogeneous sensors (where each subset can include n_s?sensors, being 1≦n_s≦7) can be configured through the Transducer Channels?70-77, by taking advantage of the communication software stack, which is embedded as Transducer Interface Module?60?and by customization of a signal conditioning?22.

The baseline implementation of the CRE-SSN architecture?10?is based on a two-board configuration consisting of: (i) Main Board?100; and (ii) Expansion Board?200.

The Main Board?100?controls the digital core consisting on: (1) an ultra-low power microcontroller MSP430F2618?106; (2) an ultra-low power RS-232 driver?107?and a 9-pin connector?103; (3) a JTAG connector?104; and (4) an expansion bus connector?105. Additionally the Main Board?100?allows for powering the CRE-SSN?10?by a battery?102?(or any power source that provides 3 volts DC), and also by AC/DC adapter where a 12 volts DC feeds a LDO Regulator?108. Connection to an LED (optional) and reset button is also provided in the Main Board?100.

The expansion board block diagram?200, as shown in FIG.?3.b,?includes customizable: (1) signal conditioning?203?(22?inFIG. 1); (2) sensor suite connections?204-211?(to integrate sensor suite functionality (21?in FIGS.?1)); and (3) communication module?202?(communication functionality?30?in?FIG. 1). The customizable signal conditioning?203?and sensor suite connections?204-211?are adapted for integrating the sensor suites formed by up to seven homogeneous or heterogeneous sensor sets, which can be a vibration sensor?90, a pressure sensor?91, a flow sensor?92, and a temperature sensor?93?as exemplified in?FIG. 2.

It is worth mentioning that the Transducer Interface Module?60?is able to provide a hardware capability is complemented for managing up to eight transducer channels?70-77, defined as TCh_x, "x" is from 0 to 7, and each of the transducer channel is driven by a single transducer (i.e. sensing element (sensor) or actuator)). In such manner, the sensor sets (such as: vibration?90; pressure?91; flow?92; and RTD?93) can be attached to the expansion board?200?while the management and configuration of the sensor sets (90-93) is conducted through the optional IEEE 1451.0 communication stack. In other words, each of the sensor sets (90-93) is conducted to each of the TCh₀-TCh_3?(70-73).

An individual set of TEDS (according to the Dot0 standard, each set is consisting on: Transducer Channel TEDS, Calibration TEDS, and User‘s Transducer Name TEDS) is connected to each attached sensor. The set of TEDS is connected to each of the Transducer Channel TCh₀-TCh_7?(70-77) by the Dot0 framework. In such manner, the TCh_x‘s associated set of TEDS each sensor (90-93?in the suite example) is completely defined. TEDS access is obtained through the Dot0 set of commands. After reading the TCh_x‘s TEDS set (for example during the initialization process), the specifications of the corresponding sensor are known. This scheme the CRE-SSN provides self-identification capability for each attached sensor and the TIM.

In order to achieve the baseline for the two-board stack of CRE-SSN, the signal conditioning?203?(22?in the CRE-SSN architecture depicted in?FIG. 1: to handle a different sensor suite) and communication module?202?(30?in the CRE-SSN architecture depicted in?FIG. 1) are able to swap, which are hosted within the expansion module?200. Accordingly, the realization of the two-board stack of CRE-SSN is enable by: (a) populating the signal conditioning?203?according to the CRE-SSN‘s requirements considering a given application (where sensor suite and signal condition can be set according to the system requirements); and (b) by designing the expansion boards?200?(where the baseline Zigbee communication module can be replaced) in compliance with the expansion bus?201, whose configuration is defined in?FIG. 4. As defined inFIG. 4, the expansion bus?201?provides access to GPIO, AID channels, powering (digital and analog), digital to analog conversion (DAC), timers, and core serial communications, such that some signals are multiplexed, wherein the selection of the delivered signal (output signal in the connector‘s pin) is conducted by software.

FIG. 2?shows that the CRE-SSN architecture?10?and its implementation have the capability of operating in conjunction with the remote Network Capable Application Processor (NCAP)?50. The microcontroller?36?of CRE-SSN dedicated to performing data acquisition, executing IEEE 1451 commands (listed in?FIG. 5), and performing intelligent functions such as: (a) sensor preprocessing; (b) diagnostics; (c) learning; (d) calibration; (e) data-validation; (f) self-healing (cluster of sensors); and (g) self-identification. Key characteristics of the CRE-SSN?10?are: (a) compliance with the Dot0 standard; (b) used of a standard API (also provided by the standard); (c) awareness mechanism built upon baseline Dot0 capabilities; (d) able to have pattern recognition by Artificial Neural Network; and (e) a stand-alone operation. Therefore, implemented resources to provide these capabilities includes:

(1) Operation capability as Raw Sensor. Since the standardized software communication stack?60?is optional, the CRE-SSN10?can be used as data collection system for accessing to communication interfaces?202?and?107?(wireless?30?and/or wired34?respectively in the CRE-SSN architecture depicted in?FIG. 1), sensor suite connections?204-211?(21?in the CRE-SSN architecture?10?depicted in?FIG. 1), and signal conditioning?203?(22?in the CRE-SSN architecture depicted in?FIG. 1). A serial communication profile is able to conduct to access the communications interface?202?(30?in the CRE-SSN architecture). The serial communication profile enables for changing the baseline Zigbee Module for any other module that operates with asynchronous serial communication according to specific application requirements (communication). Sensor suite connections?204-211?and the Transducer Channels?70-77?are adapted for attaching selected set of sensors (suite) in the expansion board?200. Then, the microcontroller?36?can be used for processing sensor data from sensor suit connections204-211?and managing communication module?30.

(2) Deployment in Modular or Standalone Fashion. The CRE-SSN?10?and a power source can be deployed for standalone configuration. A second alternative is stacking sets of CRE-SSN with a common power bus to up-scale the individual CRE-SSN capabilities within a single module.

(3) Optional Embedded Version of a Communication Protocol based on an IEEE 1451 Set of Commands (indicated as required by the standard) and Related Resources Defined by the Standard. Optional software communication stack?60?has been designed to manage networks of CRE-SSN or a single CRE-SSN. According to the Dot0 standard in the CRE-SSN, a layer shape software structure (depicted in?FIG. 2) includes: (a) a WTIM IEEE 1451.x communication module?61?(being the baseline of the Zigbee-IEEE 802.15.4 (202)); (b) TIM IEEE 1451 services?63; (c) TEDS?62?arranged within the IEEE 1451 services?63; and (d) a sensor signal processing functions?64?having a output data stream, a signal conditioner, a data conversion and a IEEE TEDS reader library. The Network Capable Application Processor (NCAP)?50?has a similar software stack structure (to provide NCAP functionality according to the Dot0 standard), which includes: (a) a NCAP IEEE 1451.x communication module?53?(Zigbee-IEEE 802.15.4); (b) NCAP IEEE 1451 services?52; and (c) NCAP application layer?51. The addressing mode of the CRE-SSN id defined by following the Dot0 convention. Data packages and commands are transferred via messages in compliance with the Dot0 standard. The embedded command set (as shown in?FIG. 5) includes commands in the following seven classes: (i) "Commands Common to the TIM and Transducer Channel", command class ID (cmdClassId)=1; (ii) "Transducer Idle State Commands", cmdClassId=2; (iii) "Transducer Operating State Commands", cmdClassId=3; (iv) "Transducer either Idle or Operating State Commands", cmdClassId=4; (v) "Sleep State Commands", cmdClassId=5; (vi) "TIM Active State Commands", cmdClassId=6; and (vii) "Any State Commands", cmdClassId=7.

FIG. 5?shows a Dot0 standard table according to the preferred embodiment of the present invention, wherein the Dot0 standard table includes: (a) the Function Number (F.N. first column); (b) the command name (second column); (c) required or not required by the standard (third column); and (d) the standard‘s clause in the IEEE 1451.0. The optional Dot0 software communication stack?60?is available for both the CRE-SSN and host computer (this last acting as the NCAP). For each class, set of implemented commands are defined in the second column of the table (FIG. 5) as follows:

• Transducer Idle State Commands: Query TEDS, Read TEDS segment, Write TEDS segment, Update TEDS, Run Self-Test, Write Service request mask, Read service request mask, Read Status-event register, Read Status-condition register, Clear status-event register, Write status-event protocol state.
• Transducer Idle State Commands: Address Group definition, Sampling Mode, Calibrate Transducer Channel.
• Transducer Operating State Commands: Read Transducer Channel data-set to segment, Write Transducer Channel data-set segment, Trigger command, Abort trigger.
• Transducer either Idle or Operating State Commands: Transducer Channel Operate, Transducer Channel Idle, Write Transducer Channel Trigger State.
• Sleep State Commands: Wake-Up.
• TIM Active State Commands: Read WTIM version, WTIM Sleep, Read Dot0 version
• Any State Commands: Reset.

The CRE-SSN software implementation allows embedding the full set of listed commands or reduced set of the listed commands as mentioned above. Implementation of the "Run Self-Test" (in the Transducer Idle State Command subset) and "Calibrate Transducer Channel" (in the Transducer Idle State Commands subset) are dependent of the attached sensor suite and the realization of the capabilities subset of the CRE-SSN. These hardware dependent commands are declared in the software and are available for customization (the user can write the required functionality within the function body).

The optional Dot0 software communication stack?60?is available for both the CRE-SSN and host computer (this last acting as the NCAP).

(4) Enhanced Dot0 Communication Software Portability for Diverse Physical Channels between NCAP IEEE 1451.x communication module?53?and WTIM IEEE 1451.x communication module?61. In order to access to the Communication Module?30?(202?in the two-board baseline implementation), the serial communication profile is provided to enable the execution of the Dot0 communication stack?60?through different physical channels (such as Zigbee, Bluetooth, or IEEE 802.11). Therefore, data formats containing commands and respond messages are transferred through the physical channel of the serial communication profile (i.e. the communication process is independent and not affected by the physical layer implementation as long as it is driven by serial communication profile).

(5) Design and Implementation of a Flexible Architecture for Customization System. The CRE-SSN baseline architecture consists on: (i) a main board?100, which provides a digital core; (ii) expansion (secondary) board?200?to enable a customization sensor; and (iii) an expansion bus?105, which provides access to I/O modules in the microcontroller?36?(as defined in?FIG. 4). The architectures of the system can be realized in a single board or board stacks (where boards are designed according to the expansion bus definition (FIG.?4‘s table)).

According to the preferred embodiment of the present invention, a two-board implementation is shown in FIG.?3.a?and FIG.3.b,?where the core capabilities of the main board?100?includes: (a) to select different power sources (primary AC/DC converter?101; battery?102; and a third optional configurable power source?102); (b) a serial communication (RS-232) connection?103; (c) a JTAG connection?104; and (d) a Digital Input/Output, timers, DAC, and ADC channels, which are available throughout the expansion connector?105.

The two-board customization implementation sensor is enabled by the expansion board?200?(connected in a stack board fashion). The expansion connector?105?provides access to the Digital Input/output and analog channels, as defined in?FIG. 4and further to the secondary board?200?through its bus connector?201. An optional Zigbee module?202?and connection to external sensors (transducers) are also available by standard connectors?204-211. Custom modules can be designed to meet specific system requirements by working with this architecture and for compliance with the expansion bus based on the MSP430 input/output modules. Since input/output modules are already available in the digital core, the bus is scalable, which allows system implementation by using a subset of the signals provided in the expansion bus. Because the communication module is designed for the operation with a Serial Communication Profile, the baseline communication module can be replaced with any other module that can be driven by an asynchronous serial communication.

(6) Designed for meeting the SWAP design requirements. The CRE-SSN architecture?10?consists of an ultra-low power solution with miniaturized form factor. The CRE-SSN dimensions (baseline sensor) are 1.82″×1.82″×1.25″ considering an external casing. The dimension of the expansion board?200?can be increased to host bigger signal conditioning circuits. The CRE-SSN architecture?10?can be also implemented in a single board. The digital core (main board?100?in the two-board realization) provides: powering?101-102; wired RS-232?communications?103; and JTAG?104.

(7) Optional Standardized Operation modes for the CRE-SSN and Transducer Channels. When Dot0 Software Stack?60?is enabled, the Dot0 Software Stack?60?of the CRE-SSN?10?can operate (as depicted in the left oval in?FIG. 6?and defined by the Dot0 standard) in the states of : (a) active; (b) sleep; and (c) initialization. Also, the Dot0 software communications stacks?60?of each Transducer Channel?70-77?can operate (as depicted in the right oval of?FIG. 6?and defined by the Dot0 standard) in the states of: (a) Operating; (b) idle; and (c) initialization.

(8) Optional Reconfigurable triggering schemes to start sampling. When Dot0 Software Stack?60?is enabled, the Dot0 Software Stack?60?of the CRE-SSN?10?can be triggering by a set of schemes as depicted in the right oval of?FIG. 7?and defined by the Dot0 standard.

(9) Optional Reconfigurable Sampling Modes. When Dot0 Software Stack?60?is enabled, the Dot0 Software Stack?60?of the CRE-SSN?10?provides a set of sampling modes consisting on: (i) individual samples; (ii) set of samples (sequence); and (iii) buffering schemes. Sampling modes are implemented according to the definitions provided by the Dot0 standard. If the Dot0 Software Stack?60?is not enabled, a fix sampling mode can be set for the operation of the CRE-SSN?10.

(10) Based on the Transducer Embedded Datasheet (TEDS). Characteristics of the selected transducer attached to the Transducer Channel?70-77?can be conducted by TEDS?62?as defined by the Dot0 standard. Five types of the TEDS are used within the CRE-SSN: (1) Meta-TEDS; (2) PHY-TEDS; (3) User‘s Transducer Name TEDS (or "XderName"); (4) Transducer Channel TEDS (or "ChanTEDS"); and (5) Calibration TEDS (or "CalTEDS"). The first four types of the TEDS are required by the standard definition. In the CRE-SSN, the overall TIM‘s attributes are defined by a set of TEDS consisting on the Meta-TEDS, PHY-TEDS, and User‘s Transducer Name TEDS. Each TIM‘s channel is associated to a different set of TEDS that enables self-identification of each sensor suites attached on the Transducer Channel?70-77. In the CRE-SSN, each Transducer Channel?70-77?is associated to a set of TEDS which is composed of Transducer Channel TEDS, Calibration TEDS, and User‘s Transducer Name TEDS. In this way, the overall characteristics of the CRE-SSN?10(and. Universal Unique Identification (UUID), embedded within the Meta-TEDS) are defined in the TIM‘s TEDS set, such that the characteristics of each channel and associated transducer are defined by the TCh‘s TEDS set.

(11) Programmer Reference Model and Sensor Self-Identification. Specifications of the CRE-SSN?10?(i.e. as a TIM) can be conducted by TEDS?62. Specifications of each TIM‘s TCh are also defined by a set of TEDS. In such manner, each common characteristics of the CRE-SSN?10?to the whole device as well as transducer attached to the CRE-SSN Transducer Channel?204-211?can be completely defined to enable self-identification. In order to incorporate with the TEDS and be based on the Dot0 standard, the related registers for its management are provided within the software stack. A programmers reference model (based on the Dot0 definition) is provided in?FIG. 8?showing the TEDS associated to the overall TIM (left side of the figure, in the left side of the vertical dashed line), and the ones associated to two channels (right top side and right bottom side) as an example of a TIM with two sensors

(12) Reconfigurable Evolutionary Algorithm Implementation by Artificial Neural Network (ANN) Design and a Standardized Framework. A two level distributed machine learning scheme is enabled. Specifically, high-level functions (evolutionary algorithms) can be integrated into the host computer (software tools in the NCAP application layer?51) for designing ANNs with different learning paradigms and collaborative behaviors. Therefore, the ANNs as mentioned above can then be transferred and embedded in the ultra-low power CRE-SSN.?FIG. 9?provides the topology of a?Multilayer?Perceptron (MLP), wherein the MLP topology is defined by the number of inputs (N), number of hidden layers (one hidden layer in?FIG. 9), number of neurons (N_h) in each hidden layer, number of outputs (M), and whether or not that there are connections between non-adjacent layers (input to output in?FIG. 9). Since the CRE-SSN Intelligent Software Elements (ISE) consisting of Artificial Neural Networks (ANN) can be deployed after training in the NCAP. The ISE includes the MLP (other ANN can be managed following the same scheme). The CRE-SSN considers a network with three layers (as defined in?FIG. 9) with an input layer of N neurons, a hidden layer of N_h?neurons, and an output layer of M neurons and the connections between the input layer and output layer (which is referred to as full connectivity), although only connections between the first and last input neuron are shown in the figure for clarity.

(13) Weight and bias values between neurons. Weight values represent the synapses effects between neurons. A weight value is required for each connection between each neuron (for example, the blue lines between the input neurons x_{p, k}(where 1≦k≦N) and hidden units in the middle layer in?FIG. 9. There will be connections between: (a) the input neurons and hidden layer; (b) the hidden layer and output layer; and (c) the input layer and output layer (since full connectivity is considered). Bias values are assigned to each unit in the hidden and output layer (depicted by the vertical line on the left of each neuron in?FIG. 9). Then, two matrices are required: (a) a first one is to define the weights between the input and hidden layer and bias, with a size of (N_h×(N+1)); and (b) a second one is to define the values of the weights between the "input and hidden layer‘s neurons" with the "output layer‘s neurons", with a size of M×(N+N_h+1).

It is worth mentioning that an MLP (ISE) is fully defined by a data structure containing a topology definition by working with this topology and weight matrices, such that the MLP (ISE) represented as:

where: (a) N_i?is the number of inputs for the i^th?MLP; (b) Nh_i?is the number of hidden units for the i^th?MLP; (c) M_i?is the number of output units for the i^th?MLP; (d) is the input weight matrix that contains the bias and weights that exist between the input neurons and the neurons in the hidden layer for the i^th?MLP; and (e) Wo_i?is the output weight matrix that contains the bias and weights that exist between the "input neurons and hidden neurons" with the "output neurons" in the i^th?MLP. Then, the i^th?MLP can be trained in the NCAP, and as a result the ANN weights and bias (contained in the W_i?and Wo_imatrices) are obtained. Next, the associated MLP_i?structure can be transferred into the CRE-SSN and the trained i^th?MLP can be used for processing new input vectors (obtained from the sensor suite) and executing intelligent health monitoring functions during the CRE-SSN operation.

(14) Reconfigurable Advanced Embedded Intelligent Functions. The CRE-SSN and host computer (NCAP when executing the Dot0 software stack) provide an advanced framework for deploying intelligent functions within target systems. In addition, trained ANN provides the building blocks for implementing Failure Detection and Identification (FDI) schemes. The NCAP controls the advanced functions, and then the resulting networks are embedded within the sensors by transferring the NN data structures (weight matrices and bias vectors) and topology (layer number and units per layer) to the CRE-SSN.

(15) Optional Asynchronous Awareness Mechanism enabled by the Dot0. When the Dot0 Software Stack?60?is enabled, the Dot0 Software Stack?60?TIM (CRE-SSN?10) initiated messages may be sent to the NCAP by using the standard‘s Status-Event Protocol State (as defined by the Dot0). In the CRE-SSN, this Dot0 capability has been used to develop fault awareness mechanism for transmitting fault information to the user in an automated way. Due to having this Dot0 framework (Status-Event Protocol State), the fault awareness mechanism combines ANN failure detection capability with the IEEE 1451.0 capabilities. When a fault condition is detected by using the sensor node‘s embedded ANN, bits?23?to?25?in the CRE-SSN‘s condition, the status event registers are updated (shown in?FIG. 8). Since the Status-Event Protocol State is enabled, the sensor can generate and transmit to the NCAP (and MMI) by a message in a 1451.0 (containing the content of the condition register) format indicating a fault.

SRC=https://www.google.com/patents/US20140200855