A system and method for zero-touch deployment for internet of things based devices

Abstract

A system and a method for zero-touch deployment for Internet of Things based devices is disclosed. An IoT-based devices (104) configured with a generic code base; a centralized repository (110) comprising firmware images of the IoT-based devices (104) organized by make, model, and version of hardware (106); a processor (202); and a memory (204) comprises instructions that, when executed by the processor (202), cause the processor (202) to: receive data inputs from hardware devices (108) establishing connection with the IoT-based devices (104), identify make, model, and version by using the generic code base automatically or via user input (106); transmit the identified make, model, and version to the centralized repository (110) for firmware update; compare the identified data with the firmware images to provide by exact match, fall back to model match, or resort to make match; download the firmware image; and replace the generic code base with specialized code. FIG. 1

Description

FIELD OF INVENTION

[0001] Embodiments of the present disclosure relate to a field of artificialintelligence and more particularly to a system and method for dynamic multi-dimensional fusion of cognitive data for synthetic intelligence.BACKGROUND

[0002] With the proliferation of Internet of Things (IoT) ecosystems, there is agrowing need for efficient and scalable methods for deploying and managing largenumbers of interconnected devices. Traditionally, onboarding and configuring IoTdevices requires manual firmware installation, hardware compatibility checks, andrepeated technician intervention. This process is time-consuming, error-prone, andnot well-suited for dynamic or large-scale environments where rapid deviceactivation is essential.

[0003] In many IoT deployment scenarios, devices are pre-loaded with limitedor placeholder firmware, which must then be updated based on the type andspecifications of one or more hardware devices. Identifying the correct firmwareimage often depends on accurate detection of the hardware's make, model, andversion. When this identification is not automated, it may involve labour-intensivemanual processes or require prior knowledge from the user or technician.

[0004] Furthermore, storage constraints on IoT devices and differences inhardware capabilities necessitate selective firmware deployment to avoid systemoverload and to ensure performance optimization. Failure in flashing processes dueto firmware mismatch or hardware misidentification can result in operationaldelays, increased support costs, and device malfunction.

[0005] Hence, there is a need for an improved system and method for zero-touchdeployment for Internet of Things based devices to address the aforementionedissue(s).OBJECTIVES OF THE INVENTION

[0006] The primary objective of the invention is to enable a zero-touchdeployment system for a plurality of Internet of Things (IoT)-based devicesconfigured with a generic code base, allowing them to autonomously identifyconnected hardware and retrieve appropriate firmware images from a centralizedrepository

[0007] Another objective of the invention is to facilitate the identification ofmake, model, and version of one or more hardware devices through automaticdetection or manual user input, thereby ensuring compatibility with availablefirmware.

[0008] Yet another objective of the invention is to enable a hierarchical firmwarematching process wherein the system provides a firmware image based on an exactmatch, falls back to a model-level match, or resorts to a make-level match in theabsence of the former, thus ensuring uninterrupted device setup.

[0009] Yet another objective of the invention is to allow selective downloadingand flashing of firmware images so as to prevent overloading the storage capacityof IoT-based devices, enabling faster boot times and improving system efficiency.

[0010] Yet another objective of the invention is to maintain a centralizedrepository containing firmware images and associated metadata, organized bymake, model, and version, to support intelligent and efficient firmwaremanagement.SUMMARY

[0011] In accordance with an embodiment of the present disclosure, a system forzero-touch deployment for Internet of Things based devices is disclosed. Thesystem includes a plurality of IoT-based devices each configured with a genericcode base. The system includes a centralized repository comprising a plurality offirmware images of the plurality of IoT-based devices organized by make, model,and version of one or more hardware devices. The system includes a processor. Thesystem includes a memory coupled to the processor, wherein the memory comprisesinstructions that, when executed by the processor, cause the processor to: receive aplurality of data inputs from one or more hardware devices in the event of the oneor more hardware devices establishing a connection with the IoT based devices,wherein the plurality of data inputs comprises a metadata of one or more hardwaredevices; identify a make, a model, and a version of the one or more hardwaredevices by using the generic code base automatically or via a user input; transmitthe identified make, model, and version of the one or more hardware devices to thecentralized repository for a firmware update; compare the identified make, modeland version of the one or more hardware devices with the plurality of firmwareimages in the centralized repository to cause the centralized repository to performone of provide a firmware image in the event of one of an exact image match, fallback to a firmware image that matches the model of the one or more hardwaredevices in the event of absence of an exact image match and resort to a firmwareimage associated with the make of the one or more hardware devices in the eventof absence of both the exact match and the model; download the firmware imageand display the firmware image onto the plurality of IoT-based devices; and replacethe generic code base with a specialized code required for the identified one or morehardware devices.

[0012] In accordance with an embodiment of the present disclosure, a methodfor zero-touch deployment for Internet of Things based devices is disclosed. Themethod includes deploying a plurality of IoT-based devices each configured with ageneric code base. The method includes organizing a plurality of firmware imagesin a centralized repository based on make, model, and version of one or morehardware devices in step. The method includes receiving, by a processor, a pluralityof data inputs from the one or more hardware devices in the event of the one ormore hardware devices establishing a connection with the IoT-based devices,wherein the plurality of data inputs comprises a metadata of the one or morehardware devices. The method includes identifying, by using the generic code base,a make, a model, and a version of the one or more hardware devices automaticallyor via a user input. The method includes transmitting the identified make, model,and version of the one or more hardware devices to the centralized repository for afirmware update. The method includes comparing the identified make, model, andversion with the plurality of firmware images in the centralized repository, causingthe centralized repository to perform one of: providing a firmware image in theevent of an exact image match, falling back to a firmware image that matches themodel of the one or more hardware devices in the event of absence of the exactimage match, and resorting to a firmware image associated with the make of theone or more hardware devices in the event of absence of both the exact match andthe model. The method includes downloading the firmware image to the IoT-baseddevice. The method includes flashing the firmware image onto the IoT-based deviceby replacing the generic code base with a specialized code required for theidentified one or more hardware devices.

[0013] To further clarify the advantages and features of the present disclosure, amore particular description of the disclosure will follow by reference to specificembodiments thereof, which are illustrated in the appended figures. It is to beappreciated that these figures depict only typical embodiments of the disclosure andare therefore not to be considered limiting in scope. The disclosure will be describedand explained with additional specificity and detail with the appended figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The disclosure will be described and explained with additional specificityand detail with the accompanying figures in which:

[0015] FIG. 1 illustrates a network environment for zero-touch deployment forInternet of Things based devices in accordance with an embodiment of the presentdisclosure;

[0016] FIG. 2 illustrates a schematic diagram of a system for zero-touchdeployment for Internet of Things based devices FIG. 1, in accordance with anembodiment of the present disclosure;

[0017] FIG. 3 is a flow chart representing the steps involved in a method for zero-touch deployment for Internet of Things based devices, in accordance with anembodiment of the present disclosure.

[0018] Further, those skilled in the art will appreciate that elements in the figuresare illustrated for simplicity and may not have necessarily been drawn to scale.Furthermore, in terms of the construction of the device, one or more components ofthe device may have been represented in the figures by conventional symbols, andthe figures may show only those specific details that are pertinent to understandingthe embodiments of the present disclosure so as not to obscure the figures withdetails that will be readily apparent to those skilled in the art having the benefit ofthe description herein.DETAILED DESCRIPTION

[0019] For the purpose of promoting an understanding of the principles of thedisclosure, reference will now be made to the embodiment illustrated in the figuresand specific language will be used to describe them. It will nevertheless beunderstood that no limitation of the scope of the disclosure is thereby intended.Such alterations and further modifications in the illustrated system, and such furtherapplications of the principles of the disclosure as would normally occur to thoseskilled in the art are to be construed as being within the scope of the presentdisclosure.

[0020] The terms "comprises", "comprising", or any other variations thereof, areintended to cover a non-exclusive inclusion, such that a process or method thatcomprises a list of steps does not include only those steps but may include othersteps not expressly listed or inherent to such a process or method. Similarly, one ormore devices or subsystems or elements or structures or components preceded by"comprises... a" does not, without more constraints, preclude the existence of otherdevices, sub-systems, elements, structures, components, additional devices,additional sub-systems, additional elements, additional structures or additionalcomponents. Appearances of the phrase "in an embodiment", "in anotherembodiment" and similar language throughout this specification may, but notnecessarily do, all refer to the same embodiment.

[0021] Unless otherwise defined, all technical and scientific terms used hereinhave the same meaning as commonly understood by those skilled in the art to whichthis disclosure belongs. The system, methods, and examples provided herein areonly illustrative and not intended to be limiting.

[0022] In the following specification and the claims, reference will be made toa number of terms, which shall be defined to have the following meanings. Thesingular forms "a", "an", and "the" include plural references unless the contextclearly dictates otherwise.

[0023] FIG. 1 illustrates a network environment for zero-touch deployment forInternet of Things based devices in accordance with an embodiment of the presentdisclosure.

[0024] Referring to FIG. 1, Further, the user may access the system (100) over anetwork (102). The network (102) may be a single communication network or acombination of multiple communication networks and may use a variety ofdifferent communication protocols. The personalized network (102) may be awireless network, a wired network, or a combination thereof. Examples of suchindividual personalized networks include, but are not limited to, Global System forMobile Communication (GSM) network, Universal Mobile TelecommunicationsSystem (UMTS) network, Personal Communications Service (PCS) network, TimeDivision Multiple Access TDMA) network, Code Division Multiple Access(CDMA) network, Next Generation Network (NON), Public Switched TelephoneNetwork (PSTN). Depending on the technology, the personalized network (102)may include various network entities, such as gateways and routers; however, suchdetails have been omitted for the sake of brevity of the present description.

[0025] In one embodiment, the system (100) is operatively coupled to a pluralityof IoT-based devices (104) each configured with a generic code base. The termplurality of IoT-based devices (104) refers to multiple embedded computing unitsdeployed across various environments, wherein each of the plurality of IoT-baseddevices (104) is capable of interfacing with one or more hardware devices (108)such as sensors, meters, dispensers, actuators, or control systems, without requiringprior configuration specific to the hardware type. The plurality of IoT-based devices(104) are designed to support plug-and-play deployment by relying on an adaptablefirmware architecture.

[0026] In an embodiment, the generic code base configured on each of theplurality of IoT-based devices (104) refers to a modular, lightweight softwareframework that contains baseline routines, communication protocols, interfacedetection mechanisms, and identification logic. The generic code base is designedto operate independently of any specific hardware make or model, thus allowingeach of the plurality of IoT-based devices (104) to intelligently detect, identify, andadapt to one or more hardware devices (108) upon installation or boot-up. Thegeneric code includes functional libraries that enable the device to performautomated diagnostics, interpret metadata from one or more hardware devices(108), and determine protocol compatibility in real time.

[0027] In one embodiment, the generic code base further comprises a library ofknown device command-response patterns, which are used during initial interfacetesting. For example, the generic code may initiate a handshake with the one ormore hardware devices (108) by sending low-level commands and analysing thecorresponding responses.

[0028] In one embodiment, the system (100) is operatively coupled to acentralized repository (110) comprising a plurality of firmware images of theplurality of IoT-based devices (104) organized by make, model, and version of oneor more hardware (108). The centralized repository (110) is configured to supportseamless identification, retrieval, and provisioning of device-specific firmware,thereby enabling remote and automated deployment across diverse hardwareecosystems.

[0029] The centralized repository (108) refers to a structured storage system,implemented on a cloud-based or on-premise server infrastructure, that securelyhosts firmware binaries, metadata files, device compatibility matrices, andassociated configuration packages. This repository is logically segmented andindexed to facilitate efficient lookup and retrieval operations based on incomingdevice information.

[0030] The plurality of firmware images within the centralized repository (108)are software builds specifically compiled to suit unique combinations of hardwarecharacteristics. Each of the plurality of firmware images is associated with aspecific make, model, and version of one or more hardware devices (108). Thecentralized repository (108) is organized using a hierarchical or key-value structuresuch that, upon receiving identification data from the connecting plurality IoT-based devices (104), the system (100) can dynamically match and serve the mostappropriate firmware.

[0031] In another embodiment, the centralized repository (110) comprises themetadata for classifying the plurality of firmware images based on functionalcompatibility across the version, the model, and the make. The metadata isstructured in a hierarchical classification schema based on functional compatibilityacross hardware make, model, and version. The metadata enables the system (100)to efficiently query and retrieve firmware images by matching incoming hardwareidentifiers to the most suitable firmware profile available in the repository.

[0032] The metadata associated with each of the plurality of firmware imagesincludes but is not limited to hardware vendor name (make), product line or featureset (model), firmware version, supported hardware revisions, date of release,compatibility notes, and checksum values for validation.

[0033] In accordance with an embodiment of the present disclosure, a system forzero-touch deployment for Internet of Things based devices is provided. The systemcomprises a processor and a machine-readable storage medium comprisinginstructions that, when executed by the processor, cause the processor to: receive aplurality of data inputs from one or more hardware devices in the event of the oneor more hardware devices establishing a connection with the IoT based devices,wherein the plurality of data inputs comprises a metadata of one or more hardwaredevices; identify a make, a model, and a version of the one or more hardwaredevices by using the generic code base automatically or via a user input; transmitthe identified make, model, and version of the one or more hardware devices to thecentralized repository for a firmware update; compare the identified make, modeland version of the one or more hardware devices with the plurality of firmwareimages in the centralized repository to cause the centralized repository to performone of provide a firmware image in the event of one of an exact image match, fallback to a firmware image that matches the model of the one or more hardwaredevices in the event of absence of an exact image match and resort to a firmwareimage associated with the make of the one or more hardware devices in the eventof absence of both the exact match and the model; download the firmware imageand display the firmware image onto the plurality of IoT-based devices; and replacethe generic code base with a specialized code required for the identified one or morehardware devices

[0034] It may be noted that the foregoing system is an exemplary system andmay be implemented as computer executable instructions in any computing orprocessing environment, including in digital electronic circuitry or in computerhardware, firmware, device driver, or software. As such, the system is not limitedto any specific hardware or software configuration.

[0035] FIG. 2 illustrates a schematic diagram of a system for zero-touchdeployment for Internet of Things based devices of FIG. 1, in accordance with anembodiment of the present disclosure. Referring to FIG. 1, the system (100)includes a processor(s) (202), a memory(s) (204) coupled to and accessible by theprocessor(s) (202), and a database (250) coupled to the memory(s) (204).

[0036] The system (100) disclosed herein is the same as the system (100)described in FIG. 1. The functions of various elements shown in the figs., includingany functional blocks labelled as "processor(s)", may be provided through the useof dedicated hardware as well as hardware capable of executing instructions. Whenprovided by a processor, the functions may be provided by a single dedicatedprocessor, by a single shared processor, or by a plurality of individual processors,some of which may be shared. Moreover, explicit use of the term "processor" wouldnot be construed to refer exclusively to hardware capable of executing instructions,and may implicitly comprise, without limitation, digital signal processor (DSP)hardware, network processor, application specific integrated circuit (ASIC), fieldprogrammable gate array (FPGA). Other hardware, standard and / or custom, mayalso be coupled to the processor(s) (202). The system (100) may further includeother components such as, but not limited to, keyboard, sensors, logic circuits,input / output interfaces etc. Further, the system (100) may include data (not shown)which may include data that may be stored, utilized or generated during theoperation of the computer implemented system (100).

[0037] The memory(s) (204) may be a computer-readable medium, examples ofwhich comprise volatile memory (e.g., RAM), and / or non-volatile memory (e.g.,Erasable Programmable read-only memory, i.e. EPROM, flash memory, etc.). Thememory(s) (204) may be an external memory, or internal memory, such as a flashdrive, a compact disk drive, an external hard disk drive, or the like.

[0038] The system (100) may be provided with a database (250) to store ageneric code, a plurality of firmware images and a specialised code. In an exampleimplementation of the system (100) including one or more servers, the databasesmay databases local to the server or may be remote to the server. It may be notedthat the data in the databases may be stored as a table or may be pre-stored as amapping with the other. This application is not limited thereto.

[0039] The system (100) may include module(s). The module(s) may include areceiving module (206), an identification module (208), transmitting module (210),a comparison module (212), a downloading module (214), and a flashing module(216). In one example, the module(s) may be implemented as a combination ofhardware and firmware. In an example described herein, such combinations ofhardware and firmware may be implemented in several different ways. Forexample, the firmware for module(s) may be processor (202) executableinstructions stored on a non-transitory machine-readable storage medium and thehardware for the module(s) may include a processing resource (for example,implemented as either single processor or combination of multiple processors), toexecute such instructions. Further, the hardware for the module(s) may includecommunication apparatuses, control circuitries involving electrical and electronicscomponents, sensors, and interface devices, which may be in communication witheach other for multi-directional communication therebetween.

[0040] Further, the system includes data. The data may include data that is eitherstored or generated as a result of functions implemented by the system. In anexample, data may include a metadata (222), a make (224), a model (226), and aversion (228). It may be noted that such examples of the various functions are onlyindicative. The present approaches may be applicable to other examples withoutdeviating from the scope of the present subject matter.

[0041] In the present examples, the non-transitory machine-readable storagemedium may store instructions that, when executed by the processing resource,implement the functionalities of modules(s). In such examples, the system (100)may include the machine-readable storage medium storing the instructions and theprocessing resource to execute the instructions. In other examples of the presentsubject matter, the machine-readable storage medium may be located at a differentlocation but accessible to the system (100) and the processor(s) (202).

[0042] In operation, the receiving module (206) is configured to receive aplurality of data inputs from one or more hardware devices in the event of the oneor more hardware devices (108) establishing a connection with the plurality of IoTbased devices (104, FIG. 1), wherein the plurality of data inputs comprises ametadata of one or more hardware devices (108, FIG. 1). This connection may bewireless (e.g., Bluetooth, Wi-Fi) or wired (e.g., USB, serial, GPIO), depending onthe physical configuration and intended application.

[0043] The plurality of data inputs refers to structured and unstructured device-level communication that is captured, parsed, and interpreted by the plurality ofIoT-based devices (104, FIG. 1) in real time. The one or more data inputs are usedto initiate a handshake protocol that forms the basis of device identification andprovisioning.

[0044] An example of the plurality of data inputs includes, but is not limited to,input / output identification strings, interface signatures, plug-and-play devicedescriptors, serial bus responses, electric signal responses, device uptimeinformation, and diagnostic codes. The plurality of data inputs may be passivelyreceived or actively polled based on the capabilities of the generic code base.

[0045] In one embodiment, the identification module (208) is configured toidentify a make, a model, and a version of the one or more hardware devices (108,FIG. 1) by using the generic code base automatically or via a user input (106, FIG.1). This identification may be carried out in two modes that is automatically via thegeneric code base or manually via the user input (106, FIG. 1).

[0046] The make refers to the manufacturer or brand associated with the one ormore hardware devices (108, FIG. 1), the model indicates the product family orcategory under which the device is marketed or structured, and the version refers tothe hardware or firmware iteration or revision number. These identifiers arenecessary to map the one or more hardware devices (109, FIG. 1) to an appropriatefirmware image in the centralized repository.

[0047] In an embodiment, the generic code base is designed to interpret thereceived metadata from the connected one or more hardware devices (108, FIG. 1)and extract parameters that correspond to standard identification markers. This mayinvolve parsing manufacturer IDs, interpreting version control tags, or analysingproduct codes embedded in the metadata.

[0048] An example of identifying make, model, and version includes, but is notlimited to, analysing a USB descriptor to retrieve vendor ID and product ID; readingI2C address space to interpret the part number and revision code of a sensor; orparsing serial communication headers to extract firmware version tags fromembedded controllers.

[0049] In another embodiment, the identification module (208) is configured toperform the identification of the make, model, and version by executing a sequenceof automated tests on an interface of the one or more hardware devices (108, FIG.1). These tests are executed by the processor in conjunction with the generic codebase resident on the plurality of IoT-based devices (104, FIG. 1), targeting thehardware interface of the one or more hardware devices (108, FIG. 1).

[0050] The automated tests are systematically performed to extract low-leveland high-level operational responses from the hardware, such as protocolhandshake behaviour, response delay, configuration register content, peripheralavailability, voltage signatures, and firmware-level metadata. These parameters arethen analysed to match preconfigured patterns or signatures stored locally or withinthe centralized repository, which correspond to known hardware configurations.

[0051] An example of the automated tests includes, but is not limited to a serialinterface probing test that checks baud rate and parity settings; a GPIO togglingroutine that measures latency and pin configuration; an I2C address sweep to detectmemory or sensor modules; an embedded command response test that verifiesbootloader strings; and a voltage / current profiling test used to determine powercharacteristics of the hardware. These tests provide key indicators which, whencorrelated, enable the processor to deduce the identity of the hardware withoutmanual intervention.

[0052] In another embodiment, the identification module (208) is configured toreceive the user input (106, FIG. 1) from a technician or the user indicative of themake, model, and version of the one or more hardware devices (108, FIG. 1) whenautomated testing fails. Upon failure of the automated testing to conclusivelydetermine the make, model, or version of the one or more hardware devices (108,FIG. 1), the identification module (208) may trigger an interface for receivingmanual inputs. This allows the technician or user to directly input identifying detailsnecessary for completing the zero-touch deployment process.

[0053] The manual input may be provided via a user interface that includes, butis not limited to a touchscreen panel, a connected mobile application, a webdashboard, or a command-line interface. The interface is designed to prompt theuser to select or enter relevant identifiers such as manufacturer name (make),product line (model), and hardware / software revision (version). This information isthen validated and used to query the centralized repository for a compatiblefirmware image, thereby enabling continuation of the firmware provisioningworkflow.

[0054] In one embodiment, the transmitting module (210) is configured totransmit the identified make, model, and version of the one or more hardwaredevices (108, FIG. 1) to the centralized repository (110, FIG. 1) for a firmwareupdate. The transmission is facilitated by the processor embedded within theplurality of IoT-based devices (104, FIG. 1), which packages the identified data intoa structured format, such as JSON, XML, or a proprietary lightweightcommunication protocol. This package includes key metadata fields representingthe identified make (e.g., "ABC Technologies"), model (e.g., "XYZ-200"), andversion (e.g., "v1.3.5") of the hardware device.

[0055] An example of transmitting the identified information includes, but is notlimited to, establishing an HTTP or MQTT connection with the centralizedrepository, constructing a payload with the identification parameters, and securelysending it via TLS / SSL encryption to an API endpoint exposed by the repositoryservice.

[0056] In one embodiment, the comparison module (212) is configured tocompare the identified make, model and version of the one or more hardwaredevices (108, FIG. 1) with the plurality of firmware images in the centralizedrepository (110, FIG. 1) to cause the centralized repository (110, FIG. 1) to performone of: provide a firmware image in the event of one of an exact image match, fallback to a firmware image that matches the model of the one or more hardwaredevices (108, FIG. 1) in the event of absence of an exact image match and resort toa firmware image associated with the make of the one or more hardware devices inthe event of absence of both the exact match and the model. The comparison module(212) compares the identified metadata with a plurality of firmware images storedin a centralized repository (110, FIG. 1). The centralized repository (110, FIG. 1) isstructured to organize firmware images according to the metadata fields such asmake, model, and version, thereby enabling precise classification and hierarchicalaccess. This hierarchical classification ensures that the system (100) can attempt tolocate the most accurate firmware match for the one or more hardware devices (108,FIG. 1), with fallback strategies in place if a precise match is unavailable.

[0057] To initiate the comparison process, the processor (202) retrieves themetadata associated with the identified one or more hardware devices (108, FIG. 1)including device manufacturer name (make), product category or configuration(model), and the specific release or revision identifier (version). These parametersare cross-referenced against corresponding metadata attributes associated with eachof the plurality of firmware images stored in the centralised repository (110, FIG.1).

[0058] In one embodiment, if an exact match is located wherein the firmwaremetadata exactly matches the identified make, model, and version the centralizedrepository causes the selected firmware image to be provided to the plurality of IoT-based devices (104, FIG. 1) for download and flashing. This step ensures optimalfirmware compatibility, performance, and hardware utilization.

[0059] In another embodiment, in the event that the centralised repository (110,FIG. 1) does not contain the firmware image that matches all three parameters(make, model, and version), the processor triggers the fallback mechanism to locatethe firmware image that matches only the model of the one or more hardwaredevices (108, FIG. 1). This model-based fallback is suitable in cases where version-level specificity is unavailable, but where firmware designed for the same hardwaremodel remains functionally compatible.

[0060] In yet another embodiment, if the centralized repository (110, FIG. 1)fails to identify the firmware image that matches either the full specification or themodel alone, the comparison module (212) then resorts to the firmware image thatis associated only with the make of the one or more hardware devices (108, FIG.1). This last-tier fallback mechanism ensures that at least a base-level firmwareimage validated for the manufacturer's hardware standards can be provisioned tothe plurality of IoT-based devices (104, FIG. 1), enabling it to function withminimal essential capabilities.

[0061] An example of a make, model, and version includes, but is not limited to,one or more hardware device (108, FIG. 1) identified as follows: make "AcmeTech", model "SmartNode V4", and version "3.1.7". The centralized repositorywould attempt to locate a firmware image with identical metadata tags. If no suchimage exists, it would seek any firmware tagged with model "Smart Node V4", andfailing that, any generic firmware under make "Acme Tech".

[0062] In one embodiment, the downloading module (214) is configured todownload the firmware image and display the firmware image onto the plurality ofIoT-based devices (104, FIG. 1). The downloading process is initiated by theprocessor (202), which establishes a secure communication session with thecentralized repository, typically using protocols such as HTTPS, MQTT, or aproprietary secure channel, ensuring that the firmware transfer maintains integrityand confidentiality.

[0063] In one embodiment, the flashing module (216) is configured to replacethe generic code base with a specialized code required for the identified one or morehardware devices (108, FIG. 1). Upon verification of the firmware image, theflashing module (216) executes an update protocol that overwrites or supplementsthe existing generic code with a more functionally rich and hardware-awarespecialized code. The specialized code includes specific drivers, protocols, andconfiguration parameters required for the optimal operation of the identifiedhardware, such as sensor calibration, peripheral integration, network stackconfiguration, and control logic.

[0064] An example of the specialized code includes but is not limited to ahardware-specific device driver for a thermal imaging sensor; a communicationstack tailored for LoRaWAN or Zigbee protocols based on the device's connectivitymodule; a machine learning module for edge processing of sensor data; or a custompower management routine designed for solar-powered nodes.

[0065] It must be noted that the replacement of the generic code base with aspecialized code is a critical transformation step that marks the completion of zero-touch provisioning. It ensures that each of the plurality of IoT-based devices (104,FIG. 1) is no longer operating in a universal fallback mode but instead behaves asa fully integrated unit customized for the one or more hardware devices (108, FIG.1) it is connected to.

[0066] In another embodiment, the flashing module (216) is configured toinitiate a retry logic to update the plurality of firmware image in the event of amismatch or failure during the flash. The retry logic is embedded as part of thecontrol flow in the memory and operates to ensure that the firmware update processcompletes reliably, especially in environments where connectivity, power, or dataintegrity may be inconsistent.

[0067] The retry logic includes, but is not limited to checksum validationfailures, hash mismatches, incomplete download errors, interrupted flash cycles,and corrupted binary image detection. In each instance, the processor is adapted toeither attempt re-download of the firmware image from the centralized repositoryor revert to a previous known stable version stored in a secure local cache forrollback.

[0068] In another embodiment, the flashing module (216) is configured to aselective downloading and flashing of the firmware image prevents overloading astorage capacity of the plurality of IoT-based devices (104, FIG. 1), therebyenabling a faster boot time and improving operational efficiency. The processor(202) uses metadata associated with the identified make, model, and version of theone or more hardware devices (108, FIG. 1) to determine the minimum viablefirmware segment needed for proper operation. This selective approach ensures thatthe one or more hardware devices (104, FIG. 1) is not burdened with unnecessarycode modules or features not applicable to its configuration, thereby conservingonboard storage.

[0069] An example of the selective downloading process includes but is notlimited to downloading only device drivers compatible with a specific hardwareinterface, excluding diagnostic or development modules not required fordeployment, or retrieving compressed firmware segments that are later unpackedand applied locally.

[0070] Consider a non-limiting example wherein a technician "T" is installingone or more hardware devices (108, FIG. 1), such as smart controllers andconnected sensors, in an industrial facility. Each of the plurality of IoT-baseddevices (104, FIG. 1) is preloaded with a generic code base to support initialoperation. As technician "T" connects a new temperature control module (ahardware device) to one of the IoT-based devices (104, FIG. 1), the deviceautomatically initiates a zero-touch deployment process. A set of data inputsincluding the metadata such as hardware serial number, manufacturer code, modelidentifier, and firmware version are detected and transmitted to the processor. Theprocessor, upon executing the embedded instructions, identifies the make, model,and version of the connected temperature control module. This information is thentransmitted to a centralized repository (110, FIG. 1), which searches for a suitablefirmware image. In this instance, there is no exact image match for the hardwareversion, so the repository falls back to a firmware image matching the model. Thefirmware image is downloaded and flashed onto the plurality of IoT-based devices(104, FIG. 1), replacing the generic code base with specialized code optimized forthe connected temperature module.

[0071] Upon successful firmware installation, then verifies the operationalreadiness through a set of automated interface tests. If the flashing fails, theprocessor automatically triggers a retry logic until a successful flash is confirmed.To optimize performance and storage, only relevant components of the firmwareimage are downloaded and applied, ensuring efficient use of device resources. Thisprevents overloading the storage capacity, accelerates boot time, and enhances theoverall operational efficiency of the plurality of IoT-based devices (FIG. 1). Duringthe process, the metadata and firmware mapping are logged and sent to a cloud-based management portal. This portal tracks firmware versioning, functionalcompatibility, and historical deployment records across the facility. As a result,technician "T" is able to deploy and configure devices rapidly without manualfirmware setup, thereby saving time and reducing the risk of configuration errors

[0072] FIG. 3 is a flow chart representing the steps involved in a method forzero-touch deployment for Internet of Things based devices, in accordance with anembodiment of the present disclosure. The method (300) includes deploying aplurality of IoT-based devices each configured with a generic code base in step 305.

[0073] The method (300) includes organizing a plurality of firmware images ina centralized repository based on make, model, and version of one or more hardwaredevices in step 310.

[0074] The method (300) includes receiving, by a processor, a plurality of datainputs from the one or more hardware devices in the event of the one or morehardware devices establishing a connection with the IoT-based devices, wherein theplurality of data inputs comprises a metadata of the one or more hardware devicesin step 315.

[0075] The method (300) includes identifying, by using the generic code base, amake, a model, and a version of the one or more hardware devices automatically orvia a user input in step 320.

[0076] The method (300) includes transmitting the identified make, model, andversion of the one or more hardware devices to the centralized repository for afirmware update in step 325.

[0077] The method (300) includes comparing the identified make, model, andversion with the plurality of firmware images in the centralized repository, causingthe centralized repository to perform one of: providing a firmware image in theevent of an exact image match, falling back to a firmware image that matches themodel of the one or more hardware devices in the event of absence of the exactimage match, and resorting to a firmware image associated with the make of theone or more hardware devices in the event of absence of both the exact match andthe model in step 330.

[0078] The method (300) includes downloading the firmware image to the IoT-based device in step 335.

[0079] The method (300) includes flashing the firmware image onto the IoT-based device by replacing the generic code base with a specialized code requiredfor the identified one or more hardware devices in step 340.

[0080] Thus, various embodiments of the system and method for zero-touchdeployment for Internet of Things based devices provides several benefits. Byutilizing a generic code base initially embedded in each of the plurality of IoT-baseddevices (104, FIG. 1) and using a centralized repository (110, FIG. 1) comprisingthe plurality of firmware images organized by make, model, and version of the oneor more hardware devices (108, FIG. 1), the system (100) eliminates the need formanual firmware flashing or configuration during deployment. The identificationmodule (208) intelligently analyses a plurality of data inputs including the metadatafrom the hardware, identifies the hardware profile, and performs comparisonoperations with the stored firmware images to ensure accurate matching. In caseswhere an exact match is not found, the system (100) seamlessly falls back to model-based or make-based firmware images, thereby ensuring operational continuity.This layered fallback logic, combined with selective downloading and flashing offirmware images, prevents overloading the plurality of IoT-based devices (104,FIG. 1) storage capacity and results in faster boot times and improved operationalefficiency, making the system highly scalable and efficient for large-scale IoTdeployments.

[0081] The techniques described in this disclosure may be implemented, at leastin part, in hardware, software, firmware, or any combination thereof. For example,various aspects of the described techniques may be implemented within one or moreprocessors, including one or more microprocessors, digital signal processors(DSPs), application-specific integrated circuits (ASICs), field-programmable gatearrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, aswell as any combinations of such components. The term "processor" or "processingsubsystem" may generally refer to any of the foregoing logic circuitry, alone or incombination with other logic circuitry, or any other equivalent circuitry. A controlunit including hardware may also perform one or more of the techniques of thisdisclosure.

[0082] Such hardware, software, and firmware may be implemented within thesame device or within separate devices to support the various techniques describedin this disclosure. In addition, any of the described units, modules, or componentsmay be implemented together or separately as discrete but interoperable logicdevices. Depiction of different features as modules or units is intended to highlightdifferent functional aspects and does not necessarily imply that such modules orunits must be realized by separate hardware, firmware, or software components.Rather, functionality associated with one or more modules or units may beperformed by separate hardware, firmware, or software components, or integratedwithin common or separate hardware, firmware, or software components.

[0083] It will be understood by those skilled in the art that the foregoing generaldescription and the following detailed description are exemplary and explanatoryof the disclosure and are not intended to be restrictive thereof.

[0084] While specific language has been used to describe the disclosure, anylimitations arising on account of the same are not intended. As would be apparentto a person skilled in the art, various working modifications may be made to themethod in order to implement the inventive concept as taught herein.

[0085] The figures and the foregoing description give examples ofembodiments. Those skilled in the art will appreciate that one or more of thedescribed elements may well be combined into a single functional element.Alternatively, certain elements may be split into multiple functional elements.Elements from one embodiment may be added to another embodiment. Forexample, the order of processes described herein may be changed and are notlimited to the manner described herein. Moreover, the actions of any flow diagramneed not be implemented in the order shown; nor do all of the acts need to benecessarily performed. Also, those acts that are not dependent on other acts may beperformed in parallel with the other acts. The scope of embodiments is by no meanslimited by these specific examples.

Claims

1. A system for zero-touch deployment for Internet of Things based devices, comprising: a plurality of IoT-based devices each configured with a generic code base; a centralized repository comprising a plurality of firmware images of the plurality of IoT-based devices organized by make, model, and version of one or more hardware devices; a processor; and a memory coupled to the processor, wherein the memory comprises instructions that when executed by the processor, cause the processor to: receive a plurality of data inputs from one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT based devices, wherein the plurality of data inputs comprises a metadata of one or more hardware devices; identify a make, a model, and a version of the one or more hardware devices by using the generic code base automatically or via a user input; transmit the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update; compare the identified make, model and version of the one or more hardware devices with the plurality of firmware images in the centralized repository to cause the centralized repository to perform one of provide a firmware image in the event of one of an exact image match, fall back to a firmware image that matches the model of the one or more hardware devices in the event of absence of an exact image match and resort to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model; download the firmware image and display the firmware image onto the plurality of IoT-based devices; and replace the generic code base with a specialized code required for the identified one or more hardware devices.

2. The system as claimed in claim 1, to cause the processor to perform the identification of the make, model, and version by executing a sequence of automated tests on an interface of the one or more hardware devices.

3. The system as claimed in claim 1, to cause the processor to receive the user input from a technician or the user indicative of the make, model, and version of the one or more hardware devices when automated testing fails.

4. The system as claimed in claim 1, wherein the centralized repository comprises the metadata for classifying the plurality of firmware images based on functional compatibility across the version, the model, and the make.

5. The system as claimed in claim 1, to cause the processor to initiate a retry logic to update the plurality of firmware image in the event of a mismatch or failure during the flash.

6. The system as claimed in claim 1, to cause the processor to a selective downloading and flashing of the firmware image prevents overloading a storage capacity of the plurality of IoT-based devices, thereby enabling a faster boot time and improving operational efficiency.

7. A method for zero-touch deployment for Internet of Things based devices, the method comprising: deploying a plurality of IoT-based devices each configured with a generic code base; organizing a plurality of firmware images in a centralized repository based on receiving, by a processor, a plurality of data inputs from the one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT-based devices, wherein the plurality of data inputs comprises metadata of the one or more hardware devices; receiving, by a processor, a plurality of data inputs from the one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT-based devices, wherein the plurality of data inputs comprises metadata of the one or more hardware devices; identifying, by using the generic code base, a make, a model, and a version of the one or more hardware devices automatically or via a user input; transmitting the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update; comparing the identified make, model, and version with the plurality of firmware images in the centralized repository, causing the centralized repository to perform one of: providing a firmware image in the event of an exact image match, falling back to a firmware image that matches the model of the one or more hardware devices in the event of absence of the exact image match, and resorting to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model; downloading the firmware image to the IoT-based device; and flashing the firmware image onto the IoT-based device by replacing the generic code base with a specialized code required for the identified one or more hardware devices.