WO2013042130A1

WO2013042130A1 - A smart hub and the method of operating thereof

Info

Publication number: WO2013042130A1
Application number: PCT/IN2011/000746
Authority: WO
Inventors: Viraj Kumar PATHI; Vamsi Khrishna SADHU; Vamsi VPRASAD; Satish MADDELA BABU; Anil Kumar VANGALA; Ramakoteshwarudu VANGALA
Original assignee: Pathi Viraj Kumar
Priority date: 2011-09-19
Filing date: 2011-10-27
Publication date: 2013-03-28

Abstract

A smart hub configured as a gateway and completes communication path between a set group of nodes (sensors) and a data collection point at remote location comprising of: a microprocessor operable for processing and control of all the peripherals by seeking their conditions from time-to-time to evaluate the working condition; a plurality of user interfaces which supports data flow from the said device to external world; a plurality of serial ports, USB ports, RJ-45 port operably connected with the said microprocessor vide interface; an oscillator in connection with the said microprocessor unit via interface to maintain the instruction clock; a memory unit for storing and processing the incoming and outgoing data; a Real Time Clock (RTC) in connection with control unit to fetch and/or set current date, time and the like; and a primary power port configured for supplying power to all components

Description

A SMART HUB AND THE METHOD OF OPERATING THEREOF

FIELD OF INVENTION

The present invention relates to a smart hub, being a device, which acts as a gateway and completes communication path between a set group of nodes (sensors) and a data collection point at remote location and the method of operating thereof. More particularly, the present invention discloses an intelligent electronic device and method configured for a gateway for selectively connecting host systems and networks with subscriber premises equipment data communication applications. The said device has the capacity to maintain robust two-way data-transactions through all the available communication ports.

BACKGROUND ART

A number of systems are available for utility companies to obtain data from a plurality of nodes (utility meters) at subscriber locations without having to send service personnel to the subscriber location to read and record meter information. For example, U.S. Patent No. 5359641 , discloses a telemetry system for accessing equipment at subscriber locations through a switching network. Control equipment in the telemetry system is configured to identify the signaling modes for loop networks connected to the subscriber locations. The signaling mode (e.g., a no signaling mode or an identified signaling mode of specified duration) for each subscriber location is stored with other customer information, as well as a reference identification number associated with equipment at the subscriber location.

A central controller used in conjunction with remotely positioned sensors or actuators can solve many measurement and control applications. In the past these transducers with the central controller over a point-to-point link were connected, which is either an analog loop, or a digital connection. More recently came a number of "field bus", making it possible that these devices use a packet-based bus or a network for communication with the central controller to share. In principle, these networks also permit communication between equals, with an intelligent device communicates directly with one another. These networks enable communication patterns on these shared media use different addressing schemes.

The process modifies configuration tables in one or more computer components (system nodes), such that packets of information that will be an application that runs in a node (a node application) are placed on the network, received from other applications correctly. Most systems use a tag-based architecture, each visible to the network entity that is created by the node applications, is given with a unique name.

A number of systems have been developed to report conditions such as power usage meter levels by initiating a telephone call to a utility company from a subscriber location. See, for example, as prior art U.S. Patent No's. 4086434, 4487892, 5239575 and 4394540. These systems are programmed to initiate a telephone call to a host computer of a utility company, for example. The telemetry reporting is typically conducted by initiating telephone calls to the host computer at predetermined intervals, such as once a month. These systems are disadvantageous for a number of reasons. For example, they can interfere with the establishment of voice calls to a telephone connected to the telephone line at the subscriber location. Further, they do not guarantee that a utility company or other service provider will be called by the subscriber, that is, the subscriber's telephone line may be out of order or disconnected or the subscriber device for connecting to a remote system may have failed. It is disadvantageous to require utility companies to passively monitor whether or not a subscriber has called and to ascertain reasons (e.g., system failure) for his or her failure to do so. It is more advantageous to centralize the functions of utility and other service providers to actively monitor a subscriber's usage of a utility or other service such as an on-line information service by initiating the telephone connection to the subscriber.

Utility metering is moving towards automation of processes such as AMR and/or AMI. To achieve a complete automation of utility meter management, it is required that the end-user is able to remotely access every end-point (i.e. the utility meter here) of the system. Hence, it is required for each of these end-points to be linked to the so called central control station which will be situated at a remote place away from the end-points.

As the size of the system increases, the number of connections at the central data collection point increases. This will increase the data traffic of the network exponentially. Every network transaction would reach the CS irrespective of significance of the data. This will have an effect on the system's performance.

An alternate solution for this is to introduce network gateways with added intelligence and responsibilities to commission, control, maintain and monitor an intended group of nodes. Gateways in the present scenario are tightly coupled devices which are developed with respect to a specific application or field area and limited resources. Such gateways have limited number of communication options and are not reusable when it comes to their usage across various fields areas.

The present invention proposes intelligent network gateways which can further increase the scope for such devices by adding additional intelligence and reducing the dependencies on physical components.

SUMMARY OF INVENTION

Therefore in order to eliminate the disadvantages as discussed in the prior art, the disclosure herein relates to an electronic device which acts as a gateway and completes communication path between a set group of nodes (sensors) and a data collection point at remote location. The device further acts as the owner for a network of nodes, which are pre-programmed to respond to their parent, i.e. the said device. The said device provides, in an exemplary embodiment, an utility in the field of metering devices / units with the meters for acquiring a plurality of meter data; while being economical with provision for option to choose the best available 'communication equipment' (wired or wireless) to form a robust communication network to make them available for remote operations. Such as herein described a smart hub configured as a gateway and completes communication path between a set group of nodes (sensors) and a data collection point at remote location comprising of: a microprocessor operable for processing and control of all the peripherals by seeking their conditions from time-to-time to evaluate the working condition; a plurality of user interfaces which supports data flow from the said device to external world; a plurality of serial ports, USB ports, RJ-45 port operably connected with the said microprocessor vide interface; an oscillator in connection with the said microprocessor unit via interface to maintain the instruction clock; a memory unit for storing and processing the incoming and outgoing data; a Real Time Clock (RTC) in connection with control unit to fetch and/or set current date, time and the like; and a primary power port configured for supplying power to all components.

As per an object of the present invention the device is configured for maintaining more than one multiple communication channels simultaneously. The choice of communication channel includes but not limited to Wi-Fi, GSM, GPRS, ZlgBee, WiMax, Ethernet, 6LowPAN.

As per another object of the present invention, the device is provided with onboard memory storage, extendable up to 32GB.

As per yet another object of the present invention, the device is provided with communication module is configured for two-way omni- potent communication network, which is wired or wirelessly connected to data port.

As per an embodiment of the present invention, there is provided provisions for a plurality of user interfaces, including but not limited to graphical LCD, TFT LCD panel with touch screen, pressure sensitive keypad.

Another embodiment of the present invention is to provide provisions for additional serial data access ports for Standard-A and Standard-B types of USB connectors.

As per another object of the present invention the said device is provided with battery back-up which can act as primary source for power in case of absence of power supply from mains. As per yet another object of the present invention the said device provides the data stored on its on-board-memory through serial ports such as USB.

As per an exemplary embodiment of the present invention, the said device is configured for the commission a network of nodes. As per yet another exemplary embodiment of the present invention the said device not only aggregates the data from its nodes but also processes it and makes it available in a common format, as desired by the end-user and sends it through selected communication channel.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

Features of the present invention will become apparent to those skilled in the art from the following description with reference to the drawings. Understanding that the drawings depict only typical embodiments of the invention and are not therefore to be considered limiting in scope, the invention will be described with additional specificity and detail through the use of the accompanying drawings, in which:

Figure-1 illustrates the block diagram of the said device in accordance with the present invention;

Figure -2 illustrates the control flow diagram of the said device in accordance with the present invention; Figure-3 illustrates the sub-task of the pre-defined process PROCESS-1 depicted in Figure-2 as performed by the said device in accordance with the present invention;

Figure-4 illustrates another sub-task of the pre-defined process PROCESS-1 depicted in Figure-2 as performed by the said device in accordance with the present invention;.

DETAILED DESCRIPTION Various exemplary embodiments of the present disclosure may be directed to a smart hub and method for providing monitoring and control. It should also be appreciated that while the device has been developed for a plurality of nodes bearing metering devices and other utility services such as electricity, water, and gas, other various applications may also be provided. In one embodiment, the electronic device described herein may be used to acts as a gateway and completes communication path between a set group of nodes (sensors) and a data collection point at remote location. The device further acts as the owner for a network of nodes, which are pre-programmed to respond to their parent, i.e. the said device. In an alternate embodiment, the said device is incorporated with a high-end microprocessor to manage multiple communication ports simultaneously, to maintain an on-board-flash-memory and to provide range of user interfaces. The said device has the capacity to maintain robust two-way data-transactions through all the available communication ports. As per another alternate embodiment, the microprocessor convert the obtained data from the nodes to a common standard data format including but not limited to ANSI, IEEE 62056-53, IEEE 62056-61 , INDIAN COSEM or a custom protocol as there which is as per the end-user for further processing after retrieval.

As illustrated in Figure-1 , which, depicts the block diagram of the said hub. The perimeter of the said device is the large perforated envelop encircling the components, excluding 1 17, 122, 121 , 120, and 123; as depicted in Figure-1.

The intelligence of the device resides inside the Micro-processor 101 enveloped by the larger rectangular frame 150. The MICRO-PROCESSO.R 101 controls, all the peripherals and seeks their conditions from time-to-time to evaluate the working condition of the said device. This MICRO-PROCESSOR 101 receives its clock from a crystal oscillator depicted as CRYSTAL 107 in Figure-1. The path 130 depicts the direction of flow from crystal oscillator CRYSTAL 107 to MICRO-PROCESSOR 101.

The said device also consists of a RAM 102, NOR-FLASH 103, NAND-FLASH 104, and RTC 105. BATTER Y-2 109 is located on the main-board depicted by perforated envelop. BATTERY-2 109 acts as a stand-by power supply to RTC 105, when power from PR ARY_POWER_SUPPLY 117 or AUXILIARY_POWER_SUPPLY 112 is not available.

Communication:

The said device has a set of serial interfaces namely SERIAL_PORT-1 at 1 19, SERIAL_PORT-2 at 1 18 and SERIAL_PORT-3 at 124 along with other local communication ports namely USB-A at 1 1 , USB-B at 110 and RJ-45 at 1 16.

SERIAL_PORT-1 119 and SERIAL_PORT-2 118 are dedicated for interfacing with communication modules COMMUNICATION_MODULE-1 at 120 and COMMUNCIATION_MODULE-2 at 121 respectively. The paths 144 and 143 indicate the directions of data flow between respective components. The communication modules are interfaced to the said device through suitable interface mechanism at the respective serial ports as depicted in Figure-1. The SERIAL_PORT-1 119 and SERIAL_PORT-2 1 18 are further connected to the MICRO-PROCESSOR 101 via paths 141 and 140 respectively. Paths 141 and 140 indicate the direction of data flow between respect serial ports and the MICRO-PROCESSOR 101.

NOTE:

The communication modules COMMUNICATION JV1ODULE-1 at 120 and COMMUNCIATION_MODULE-2 at 121 are shown out of the perforated box in the Figure-1. This is because the said device has the ability to integrate with a range of communication devices. Thus the said device will provide for inclusion of a communication module of desired type.

The data ports at 123 and 122 respectively, are the representation of the communication modules' own data ports.

The said device further has an additional serial port SERIAL-PORT-3 124 as a local data port to maintain communication with the MICRO-PROCESS 101.

The said device has additional local data access ports namely USB-A at 11 1 and USB- B at 110 respectively. USB-A 1 11 can be used to interface any standard USB device with Standard-A type connector. USB-A 1 11 can be used to interface any standard USB device with Standard-A type connector. The USB ports USB-A at 1 1 1 and USB-B at 1 10 are connected to the MICROPROCESSOR 101 via paths 138 and 137 respectively. The directions of paths 138 and 137 indicate the direction of data flow between MICROPROCESSOR 101 and respective USB ports.

The said device also has an RJ-45 1 16 to connect a standard Ethernet jack. Through this port the end user can directly access the data from the said device via Ethernet. RJ- 45 1 16 port is connected to the MICROPROCESSOR 101 via path 136 and the direction of the path indicated the direction of data flow between MICROPROCESSOR 101 and RJ-45 116.

POWER PORT:

The said device is energized at POWER_PORT 125. The POWER_PORT 125 has a dual connection to be able to draw power from either PRIMARYpOWER_SUPPLY at 117 or AUXILIARYpOWER_SUPPLY at 1 12 as depicted in Figure-1. The PRIMARYpOWER_SUPPLY 1 17 provides the said device with a continuous DC power supply of desired voltage.

The AUXILIARYP0WER_SUPPLY 112 is connected to the POWERPORT125 through two paths 149 and 148 respectively. When the PRIMARYpOWER_SUPPLY 7 is available the AUXILIARYpOWER_SUPPLY 1 2 draws its recharge power from POWERPORT 125 via path 148. If the PRIMARYpOWER_SUPPLY 117 fails to supply power to the device, then the AUXILIARY_POWER_SUPPLY 1 12 will supply power to the said device to POWERPORT 25 via path 149.

In scenarios where the availability of continuous mains DC power is scarce the AUXILIARYpOWER_SUPPLY 1 12 will be replaced with a suitable battery, which then acts as the primary power supply to the board. Under such condition the path 148 remains dormant.

USER INTERFACES: The said device has provision for 3 types of user interfaces namely - USERJNTERFACE-1 at 113, USERJNTERFACE-2 at 114 and USERJNTERFACE-3 at 115.

USERJNTERFACE-1 113 is a unidirectional user interface which supports data flow from the said device to external world but not vice versa as depicted by the path 133. This interface can be used with user interfaces including but not limited to a Graphical LCD.

USERJNTERFACE-2 114 is a unidirectional user interface which supports data flow to the said device from external world but not vice versa as depicted by the path 134. This interface can be used with user interfaces including but not limited to a pressure sensitive Keypad.

USERJNTERFACE-3 5 is a bi-directional user interface which supports bi-directional data flow between the said device and external world as depicted by the path 135. This interface can be used with user interfaces including but not limited to a TFT LCD panel with touch screen.

The Figure-2, Figure-3 & Figure-4, depicts the control flow in the said device while the said device is energized and is in operation.

The flow has been further broken down in to three separate parts namely Figure-2, Figure-3 & Figure-4 for convenience of distinguishing between 'Main Routine' and the rest of the 'Sub-routines'.

NOTE: The following connectors in of Figure-2, Figure-3 and Figure-4 are representing the same positions and lead to the same point in the flow in the control flow of the said device.

Connector 205 of Figure-2 equals connector 306 of Figure-3 and connector 410 of Figure-4 respectively.

Connector 222 of Figure-2 equals connector 311 of Figure-3 and connector 411 of Figure-4 respectively. Connector 214 of Figure-2 equals connector 312 of Figure-3 Connector 215 of Figure-2 equals connector 401 of Figure-4 Connector 301 of Figure-3 equals connector 407 of Figure-4

As illustrated, the flow in Figure-2 is explained as follows. It has two parts separated by the thick vertical line as depicted in the Figure-2.

PART-1

The said device gets energized upon POWER_ON as depicted at 201. When the said device is enters the state of POWERJDN 201, it checks for levels of the ON_BOARD_VITAL_PARAMETERS including but not limited to currents, voltages, and signal rates. After fetching the data regarding ON_BOARD_VITAL_PARAMETERS the device will move to decision point 203.

CASE-1 :

If the levels of respective ON_BOARD_VITAL_PARAMETERS are at desired levels the device will generate SYSTEM_READY signal. Then the device control moves to the pre-defined process PROCESS-1 depicted as 204.

At PROCESS-1 204, the said device commissions a network of SUBORDINATEJMODES through the communication channel C O M M 2_C H AN N E L, by sending a request to all the pre-programmed SUBORDINATE_NODES to respond to the said device through respective communication channel COMM2_CHANNEL. The system flow will then shift to 205.

CASE-2:

If the levels of respective ON_BOARD_VITAL_PARAMETERS are not at desired levels the device will not generate SYSTEM_READY signal. Then the device control shifts to 206 where the system generates DEVICE_DIAGNOSIS message. The system then reaches the decision point 207, where it checks for the availability of communication channel COMM1 CHANNEL. If communication channel COMM1_CHANNEL is available, the said device will send the generated DEVICE_DIAGNOSIS message through communication channel COMM1_CHANNEL as depicted at 209. This transaction of the said device is stored in to ON_BOARD_MEMORY as depicted at 210. Then the device will enter DORMANT_MODE as depicted at211 to reduce the power consumption.

If communication channel COMM1_CHANNEL is not available, the said device will store the generated DEVICE_DIAGNOSIS message in to ON_BOARD_MEMORY as depicted at 210. Then the device will enter DORM ANT_M ODE as depicted at 211 to reduce the power consumption. PART-2:

Under success scenario as explained in CASE-1 of PART- of Figure-2, the flow reaches to 205 in PART-2 and waits for any event to occur upon the said device.

If an EVENT occurs, the decision point 212 will lead the flow to decision point 213. Here the device verifies if the occurred event is due to data signal from communication channel COMM1-CHANNEL i.e. COMM1_EVENT. If the occurred EVENT is COMM1_EVENT, the device control flow will shift to COMM1_EVENT_HANDLER depicted at 214.

If the occurred EVENT is not a COMM1_EVENT, the device then shifts the control to decision point 215. The device then verifies if the event is due to data signal from communication channel COMM2-CHANNEL i.e. COMM2_EVENT as depicted at 215. If the occurred EVENT is COMM2_EVENT, the device control flow will shift to COMM2_EVENT_HANDLER depicted at 216.

If the occurred EVENT is not a COMM2_EVENT, the device then shifts the control to process at 217 to identify the EVENT_TYPE. Then the device will initiate a pre-defined process for handling NON_COMMUNICATION_EVENTs as depicted at 218. After completion of the pre-defined process at 218, the device reaches decision point 219.

At decision point 219, the device checks for availability of communication channel COMM1 CHANNEL. If communication channel COMM1 CHANNEL is available the device generates EVENT_MESSAGE as depicted at 221 and reaches COMM1_HANDLER as depicted at 222. The process at COMM 1 JHANDLER is described in the following sections while Figure-4 is described.

Further as illustrated in Figure-3 having two parts separated by the thick vertical line as depicted in the Figure-3. The flow in each part is explained in the sub-sections below.

PART-1:

The flow diagram in PART-1 of Figure-3 depicts the sub-task performed by the said device. The cause of this sub-task is the pre-defined process PROCESS- depicted in Figure-2 as 204. From 301 the device reaches the decision point 302. At decision point 302 the said device verifies whether all the SUBORDINATEJMODES had responded or not.,

If all the SUBORDINATE_NODES had responded, the device will generate N ETWO R K_R E AD Y message and shift the control to 306. At connector 306 the device will enter IDLE state waiting for an EVENT to occur as depicted in the Figure-2 between 205 and 212.

If some of SUBORDINATEJMODES had not responded, the control will shift to 303 where a pre-defined process will re-issue the REQUEST_TO_RESPOND command to the NON-RESPONDENTJMODES. Then the device will verify if the condition for ALL_NODES_RESPOND is satisfied at decision point 304. If the condition at 304 is satisfied the device will generate NETWORK_READY message and shift the control to 306. At connector 306 the device will enter IDLE state waiting for an EVENT to occur as depicted in the Figure-2 between 205 and 212.

If the condition ALL_NODES_RESPOND is not satisfied at 304, the device will generate RESPONSE_FAILURE messages for the respective NON-RESPONDENTJMODES. Then the device will further prepare to send the respective data the communication channel COMM1_CHANNEL as depicted at 308. The device control will then move to CO M1 HANDLER at 309. PART-2:

The flow diagram in PART-2 of Figure-3 depicts a sub-task performed by the said device. The system control reaches this part of the flow from 214 of Figure-2.

Starting point of PART-2 is 310. The device receives data through communication channel COMM1_CHANNEL at 311. A pre-defined process further validates this RECEIVED_DATA at 312. The device will then verify DATA_VALID signal at decision point 313.

If DATA_VALID at 313 is satisfied, the device will further process the RECEIVED_DATA as depicted at 315. The device will then check if the data is for communication channel COMM2_CHANNEL, at decision point 316.

At 316, if DATA_FOR_COMM2 is satisfied, the data is sent through communication channel COMM2_CHANNEL the respective destination.

If DATA_FOR_COMM2 is not satisfied, the device reaches decision point 318. Here the device verifies if it is a request for memory read represented as MEMORY_REQUEST. If it is MEMORY_REQUEST, the said device will collect the respective data from ONJ3OARD_MEMORY. The device will then prepare to send data through communication channel COMM1_CHANNEL The device control will then move to COMM1_HANDLER at 309.

However, if at decision point 313 if data was found not valid. That is DATA_VALID is not satisfied at 313, the device will prepare to send the RECEIVED_DATA through communication channel COMM1_CHANNEL. The device control will then move to COMM1_HANDLER at 309.

As illustrated, Figure-4 has two parts separated by the thick vertical line as depicted in the Figure-4. The flow in each part is explained in the sub-sections below. PART-1 :

The flow diagram in PART-1 of Figure-4 depicts a sub-task performed by the said device. The system control reaches this part of the flow from 216 of Figure-2. Starting point of PART-1 is 401. The device receives data through communication channel COMM2_CHANNEL at 402. This RECEIVED_DATA is further validated by a pre-defined process at 403. The device will then verify the DATA_VALID signal at decision point 404. If DATA_VAUD at 404 is satisfied, the device will check if the data is received as a result of PROCESS-1 depicted as 204 in Figure-2. If the data is due to PROCESS-1 , the decision point will lead to 407 which lead the control to PROCESS-1JHANDLER at 301 of Figure-3.

Else if the data is not due to PROCESS-1 , the device will further process the RECEIVED_DATA as depicted at 408. The device will then check if the data is for communication channel COMM1_CHANNEL, at decision point 409. If the data is intended for communication channel COMM1_CHANNEL i.e. if DATA_FOR_COMM1 is satisfied, the device will invoke COMM1_HANDLER at 411. Else if DATA_FOR_CO M 1 is not satisfied, the control will shift to 410 where the device enters an IDLE state waiting for an event to occur.

The events occurring are classified based on their priority as POWER_FAILURE, NON_COMMUNICATION_EVENT, and COMM_EVENT respectively.

PART-2:

The flow diagram in PART-2 of Figure-4 depicts a sub-task performed by the said device. The system control reaches this part from various points in the flow such as 222 of Figure-2, 309 of Figure-3 and 411 of Figure-4.

COMM1_HANDLER:

Starting point of PART-2 is 412. The device will then decision point 413 where it checks if the respective communication channel COMM1_CHANNEL is available. If communication channel COMM1_CHANNEL is available, the device sends the intended data through communication channel COMM1_CHANNEL and stores the COMM1 TRANSACTION and its SUCCESS STATUS in to ON BOARD MEMORY. If communication channel COMM1_CHANNEL is NOT available, the device stores the COMM1_TRANSACTION and its SUCCESS_STATUS in to ON_BOARD_MEMORY.

Feature 1 :

The said device is intended to have provisions for implementing more than one communication modes simultaneously. It has dedicated lines to which a communication module can be connected through suitable interface. This gives the users the choice to choose a communication module, to place on the said device. The choice of communication channel includes but not limited to Wi-Fi, GSM, GPRS, ZlgBee, WiMax, Ethernet, 6LowPAN. Feature.?:

The said device in the invention is developed in such a fashion to have a default provision for connecting to a flash memory. The user can use this interface to include a local memory device such as including but not limited to SD card, micro SD card. The said device can thus maintain an on-board-memory. This memory will be of flash type. The storage capacity of the said on-board-memory will range between 2GB and 32GB.

Feature3:

The said device has been provided with provisions for connecting user interfaces such as including but not limited to graphical LCD, TFT LCD panel with touch screen, pressure sensitive key pad. The lines for these user interfaces are separate and dedicated.

Featured

The said device gives the end-users the convenience to have local data exchange ports for transferring data from and to the said device. These data ports can be USB standard based serial data ports. For the convenience of end-users there is a provision on the said device to have USB connections type of Standard-A and Standard-B. Feature5:

The said device is provided with dual power-modes. This enables the device to operate either on mains-supply or on battery supply. Here the invention further provides the flexibility to choose the battery supply as either primary or auxiliary supply based on the use of the said device.

If the said device is used on main-supply and if the main-supply goes off, the battery will work as a back-up. Whereas, if the said device is to be deployed in such places where a continuous power supply is scarce then the battery supply can be used as the primary source of power supply. Feature6:

The additional serial data ports on the said device i.e. the USB ports can be used to retrieve data from the on-board-memory of the said device. Also the same USB ports can be used to send data to the on-board-memory for storage.

Feature7: The said device has the intelligence to commission a network of nodes designate to respond to it. Upon power-on the said device forms a suitable network for the set of preprogrammed group of nodes to join the network.

Feature8:

The said device further has the ability to receive data on multiple channels, process it and send to the intended destination through respective communication channels.

The said device when listening to its subordinate nodes will not only aggregates the data from the nodes but also processes it. This data is further put into a desired common format. The data in the desired format is then sent through selected communication channel Numerous modifications may be made to the present invention, which still fall within the intended scope hereof. Thus, it should be apparent that there has been provided in accordance with the present invention a method and apparatus for welding with a robotic system that fully satisfies the objectives and advantages set forth above. Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

Claims

CLAIMS:

1. A smart hub configured as a gateway and completes communication path between a set group of nodes (sensors) and a data collection point at remote location comprising of: a microprocessor operable for processing and control of all the peripherals by seeking their conditions from time-to-time to evaluate the working condition; a plurality of user interfaces which supports data flow from the said device to external world; a plurality of serial ports, USB ports, RJ-45 port operably connected with the said microprocessor vide interface; an oscillator in connection with the said microprocessor unit via interface to maintain the instruction clock; a memory unit for storing and processing the incoming and outgoing data; a Real Time Clock (RTC) in connection with control unit to fetch and/or set current date, time and the like; and a primary power port configured for supplying power to all components.

2. A smart hub as claimed in claim 1 , wherein a plurality of communication modules are operably connected with the said microprocessor vide a plurality of serial ports to maintain a two way communication with its network gateway, nodes and data collection point through respective communication channels;

3. A smart hub as claimed in claim 1 , wherein the said device has the ability to integrate with a range of communication devices and thereby inclusion of a communication module of desired type.

4. A smart hub as claimed in claim 1 , wherein the communication module is configured for two way omni- potent communication network which is wired or wirelessly connected to data port.

5. A smart hub as claimed in claim 1 , further comprises of auxiliary (secondary) power supplies to increase the availability of the device even in the event of power failure at the mains (primary) power supply.

6. A smart hub as claimed in claim 1 , wherein the plurality of various data ports configured for the data acquisition and transfers compatible with the data ports available at the various nodes and communication module.

7. A smart hub as claimed in claim 1 , wherein the microprocessor convert the obtained data from the nodes to a common standard data format including but not limited to ANSI, IEEE 62056-53, IEEE 62056-61 , INDIAN COSEM or a custom protocol as there which is as per the end-user for further processing after retrieval.

8. A smart hub as claimed in claim 1 , wherein the communication module is configured to integrate with variety of communication modules of different modes of communication include but not limited to zigbee, 6L0WPAN, other devices communicating on low power ISM band frequencies.

9. A smart hub as claimed in claim 1 , wherein the memory unit is configured for limiting the data collection cycle to a very minimum numbers by storing all the transactions into the on-board-memory and transmitting if an explicit data request is received over the communication channel.

10. A smart hub as claimed in claim 1 , wherein the microprocessor is programmed to schedule for events such as including but not limited to communication activities, utility interaction, and respective device health check-up, vital system performance parameters which include system voltage, peripheral controls, data ports at planned- intervals and the like.

11. A smart hub as claimed in claim 1, wherein the duty cycle can be reduced by putting the device at dormant state for longer periods and only allowing priority events by limiting the various transactions and making them purely request based for reducing the power consumption.

12. A smart hub as claimed in claim 1 , wherein the RJ-45 1 16 port is configured to connect a standard Ethernet jack from where the end user can directly access the data from the said device via Ethernet.

13. A method for operating a smart hub comprising the steps of: energizing through main power supply upon availability of power; checking for the performance by reading into ON_BOARD_VITAL_PARAMETERS; fetching the data related to O N_BO AR D_V I TAL_P AR AM ET E R S and validating the received values and raising the fag for SYSTEM_READY; deciding the process path based on the status of SYSTEM_READY flag .

14. A method for operating a smart hub as claimed in claim 13, wherein in the event of the system being not ready, further comprising the steps of: generating DEVICE_DIAGNOSIS message; storing the message into the ON_BOARD_MEMORY; sending the device into DORMANT_MODE.

15. A method for operating a smart hub as claimed in claim 13, wherein in the event of the system being ready, further comprising the step of: requesting all the SUBORDINATE NODE on COMM2_CHANNEL to respond awaiting for event occurance; wherein under condition of any occurance of an event, initiating the TRIGGER_PROCESS; determining the state of the event for COMM1_EVENT or COMM2_EVENT or else EVENT JYPE; wherein under condition of a NONCOMMUNICATION _EVENT storing the said event in ON-Board memory or sending the EVENT MESSAGE over COMM1_CHANNEL.

16. A method for operating a smart hub as claimed in claim 13 or 14, wherein in the events are classified based on their priority as POWER_FAILURE, NON_COMMUNICATION_EVENT, and COMM_EVENT respectively