Unit 4 Notes (Some Topics) for Students PDF

Unit 2 Syllabus: Iot Reference Architecture: Introduction, Functional View, Information View, Deployment and Operational View, Other Relevant Architectural views. Real-World Design Constraints- Introduction, Technical Design constraints. Iot Reference Architecture: The reference architecture con...

Unit 2 Syllabus: Iot Reference Architecture: Introduction, Functional View, Information View, Deployment and Operational View, Other Relevant Architectural views. Real-World Design Constraints- Introduction, Technical Design constraints. Iot Reference Architecture: The reference architecture consists of a set of components. Layers can be realized by means of specific technologies, and we will discuss options for realizing each component. There are also some cross-cutting/vertical layers such as access/identity management. Fig: IoT Reference architecture The layers are 1) Client/external communications - Web/Portal, Dashboard, APIs 2) Event processing and analytics (including data storage) 3) Aggregation/bus layer – ESB and message broker 4) Relevant transports - MQTT/HTTP/XMPP/CoAP/AMQP, etc. 5) Devices The cross-cutting layers are 6) Device manager 7) Identity and access management 1) The Device Layer: The bottom layer of the architecture is the device layer. Devices can be of various types, but in order to be considered as IoT devices, they must have some communications that either indirectly or directly attaches to the Internet. Each device typically needs an identity. The identity may be one of the following: A unique identifier (UUID) burnt into the device (typically part of the System-on-Chip, or provided by a secondary chip) A UUID provided by the radio subsystem (e.g. Bluetooth identifier, Wi-Fi MAC address) An OAuth2 Refresh/Bearer Token (this may be in addition to one of the above) An identifier stored in nonvolatile memory such as EEPROM For the reference architecture we recommend that every device has a UUID (preferably an unchangeable ID provided by the core hardware) as well as an OAuth2 Refresh and Bearer token stored in EEPROM. 2 ) The Communications Layer: The communication layer supports the connectivity of the devices. There are multiple potential protocols for communication between the devices and the cloud. The well known three potential protocols are HTTP/HTTPS (and RESTful approaches on those) MQTT 3.1/3.1.1 Constrained application protocol (CoAP) HTTP is well known, and there are many libraries that support it. Because it is a simple text based protocol, many small devices such as 8-bit controllers can only partially support the protocol. The larger 32-bit based devices can utilize full HTTP client libraries that properly implement the whole protocol. There are several protocols optimized for IoT use. The two best known are MQTT6 and CoAP7. MQTT was invented in 1999 to solve issues in embedded systems and SCADA. It has been through some iterations and the current version (3.1.1) is undergoing standardization in the OASIS MQTT Technical Committee8. MQTT is a publish-subscribe messaging system based on a broker model. CoAP is a protocol from the IETF that is designed to provide a RESTful application protocol modeled on HTTP semantics, but with a much smaller footprint and a binary rather than a text-based approach. CoAP is a more traditional client-server approach rather than a brokered approach. CoAP is designed to be used over UDP. 3) The Aggregation/Bus Layer: An important layer of the architecture is the layer that aggregates and brokers communications. This is an important layer for three reasons: 1. The ability to support an HTTP server and/or an MQTT broker to talk to the devices; 2. The ability to aggregate and combine communications from different devices and to route communications to a specific device (possibly via a gateway) 3. The ability to bridge and transform between different protocols, e.g. to offer HTTP based APIs that are mediated into an MQTT message going to the device. The aggregation/bus layer provides these capabilities as well as adapting into legacy protocols. The bus layer may also provide some simple correlation and mapping from different correlation models (e.g. mapping a device ID into an owner’s ID or vice-versa). Finally the aggregation/bus layer needs to perform two key security roles. It must be able to act as an OAuth2 Resource Server (validating Bearer Tokens and associated resource access scopes). It must also be able to act as a policy enforcement point (PEP) for policy-based access. 4) The Event Processing and Analytics Layer: This layer takes the events from the bus and provides the ability to process and act upon these events. A core capability here is the requirement to store the data into a database. This may happen in three forms. The traditional model here would be to write a server side application, e.g. this could be a JAX-RS application backed by a database. However, there are many approaches where we can support more agile approaches. The first of these is to use a big data analytics platform. This is a cloud- scalable platform that supports technologies such as Apache Hadoop to provide highly scalable map reduce analytics on the data coming from the devices. The second approach is to support complex event processing to initiate near real-time activities and actions based on data from the devices and from the rest of the system. Our recommended approach in this space is to use the following approaches: Highly scalable, column-based data storage for storing events Map-reduce for long-running batch-oriented processing of data Complex event processing for fast in-memory processing and near real-time reaction and autonomic actions based on the data and activity of devices and other systems In addition, this layer may support traditional application processing platforms, such as Java Beans, JAX-RS logic, message-driven beans, or alternatives, such as node.js, PHP, Ruby or Python. 5) Client/External Communications Layer: The reference architecture needs to provide a way for these devices to communicate outside of the device-oriented system. This includes three main approaches. Firstly, we need the ability to create web-based front-ends and portals that interact with devices and with the event-processing layer. Secondly, we need the ability to create dashboards that offer views into analytics and event processing. Finally, we need to be able to interact with systems outside this network using machine-to-machine communications (APIs). These APIs need to be managed and controlled and this happens in an API management system. The dashboard is a re-usable system focused on creating graphs and other visualizations of data coming from the devices and the event processing layer. The API management layer provides three main functions: The first is that it provides a developer-focused portal (as opposed to the user focused portal previously mentioned), where developers can find, explore, and subscribe to APIs from the system. There is also support for publishers to create, version, and manage the available and published APIs; The second is a gateway that manages access to the APIs, performing access control checks (for external requests) as well as throttling usage based on policies. It also performs routing and load-balancing; The final aspect is that the gateway publishes data into the analytics layer where it is stored as well as processed to provide insights into how the APIs are used. 6) Device Management: Device management (DM) is handled by two components. A server-side system (the device manager) communicates with devices via various protocols and provides both individual and bulk control of devices. It also remotely manages software and applications deployed on the device. It can lock and/or wipe the device if necessary. The device manager works in conjunction with the device management agents. There are multiple different agents for different platforms and device types. The device manager also needs to maintain the list of device identities and map these into owners. It must also work with the identity and access management layer to manage access controls over devices (e.g. who else can manage the device apart from the owner, how much control does the owner have vs. the administrator, etc.) There are three levels of device: non-managed, semi-managed and fully managed (NM, SM, and FM). Fully managed devices are those that run a full DM agent. A full DM agent supports: Managing the software on the device Enabling/disabling features of the device (e.g. camera, hardware, etc.) Management of security controls and identifiers Monitoring the availability of the device Maintaining a record of the device’s location if available Locking or wiping the device remotely if the device is compromised, etc. Non-managed devices can communicate with the rest of the network, but have no agent involved. Semi-managed devices are those that implement some parts of the DM (e.g. feature control, but not software management). 7) Identity and Access Management: The final layer is the identity and access management layer. This layer needs to provide the following services: OAuth2 token issuing and validation Other identity services including SAML2 SSO and OpenID Connect support for identifying inbound requests from the Web layer XACML PDP Directory of users (e.g. LDAP) Policy management for access control (policy control point) The identity layer may of course have other requirements specific to the other identity and access management for a given instantiation of the reference architecture. In order to address the concerns of mainly the concrete IoT architect, and secondly the concerns of most of the above stakeholders, we have chosen to present the Reference Architecture as a set of architectural views A Reference Architecture, on the other hand, serves as a guide for one or more concrete system architects. However, the concept of views for the presentation of architecture is also useful for the IoT Reference Architecture. Views are useful for reducing the complexity of the Reference Architecture blue prints by addressing groups of concerns one group at a time. 1) Functional View: Description of what the system does, and its main functions. 2) Information View: Description of the data and information that the system handles. 3) Development View: defines how to implement the system. 4) Operational View: defines how to keep the system alive in the field. 5) Deployment View: defines how to transition the system to live operation. Fig: various views in IoT 1) Development View: The Development View defines how to implement the system. The Development View addresses the concerns of developers and testers. All software projects involve some amount of new code being written.This view provides a stable environment for more detailed design work. 2) Deployment View: The Deployment View defines how to transition the system to live operation. Focuses on aspects of the system important after the system has been built and is ready to be put into live operation. It defines -The physical environment it will run in. -Hardware and hosting environment (processing nodes, network interconnections, disk storage). -Technical environment requirements for each processing node. - Mapping of elements to the runtime environment that will execute them. It is needed when the system has- -Complex runtime dependencies. - Third party libraries, network services. - Complex runtime environments. -Elements distributed across many machines. -Dependencies on unfamiliar HW/SW. -Deployed on cloud hardware. - When the system will be deployed in wildly varying software environments. - Commercial software runs on a PC. - Wildly varying physical environments. - Specialist or unfamiliar hardware. 3) Operational View: The Operational View defines how to keep the system alive in the field It identifies a system-wide strategy for addressing operational concerns. It helps to ensure system is a reliable and effective part of its environment. For packaged software, it helps to illustrate the types of issues that could occur once installed. It documents how the system can be architected to reduce or address these concerns. The Operational View is the often least well-defined view, as many of the details are not fully-defined until construction is underway 3.1) Installation and upgrade Operation team performs the install. Sometimes users install and configure themselves. In installation and upgrade it checks/validates- - Resources allocated to a cloud environment. -Is this a pure installation or an upgrade? -Upgrades can be more complex. It must respect existing data and settings, state of running elements. -Can you keep the system running during update? - Ensure the system can be installed or updated successfully. 3.2) Documenting Installation and Upgrade It help the reader understand: What needs to be installed or upgraded to move the system into production? What dependencies exist between groups of items to be installed or upgraded (determines event order). What constraints exist on the installation process? What needs to be done to abandon and undo the installation/upgrade if there is a problem? Do not need a complete guide. Instead, constraints the architecture imposes on installation and upgrade. 3.3) Operational Monitoring and Control: In Operational Monitoring and Control it checks- -Does systems require routine monitoring? Which control operations can be used to keep the system running correctly. -Startup, shutdown, transaction resubmission. -How much is required depends on how many unexpected operational conditions are likely to occur. -Balance against cost and time. -Consider deployment environment to identify solutions. 3.4) Alerting: A system should send notifications when something bad happens. - Technical alert: Unable to connect to database. -Functional alert: Bad data on an automated input. Significant non-error conditions (startup, shutdown) Active function of a system. Alert should be sent to appropriate humans for action. It defines which events require alerts, what information should be included, and where it should be sent. Avoid sending too many alerts 3.5) Backup and Restore: Data must be protected and insured. -for that Backup processes should be designed, built, and tested regularly. -It must be possible to restore data from a backup in a transactionally consistent state. -All updates committed to the restored database or not recovered at all, must be checked regularly. -Consider data lost as part of restoring (at least any transactions active during failure). -Failure in one element could corrupt system. -Recover or recreate lost data. Revert system to older state. 3.6) Documenting System Administration: It contains monitoring and control facilities. How to monitor and adjust the system. Custom utilities, existing management environments. Basic message log to full-blown infrastructure. Define what features you will offer, how to use them, and any limitations. Required routine procedures What needs to be performed regularly? What are the Backup and health check procedures? Define purpose of each procedure, when performed, who performs it, and the steps involved. The likely error conditions Error conditions may require administrative intervention (disk full, network failure). What is unique about architecture? Explain error conditions, when they occur, how to recognize them, and HOW to correct them. Performance monitoring facilities. Watch the system for performance problems Explain measures taken, how they can be extracted and analyzed. 4) Functional view: Fig : Functional view The functional view for the IoT Reference Architecture is presented in Fig ,and is adapted from IoT- A architecture. It consists of the Functional Groups (FGs) presented earlier in the IoT Functional Model, each of which includes a set of Functional Components (FCs). It is important to note that not all the FCs are used in a concrete IoT architecture, and therefore in the actual system as explained earlier 4.1) Device and Application functional group: The Device and Application FGs are already covered in the IoT Functional Model. For convenience the Device FG contains the Sensing, Actuation, Tag, Processing, Storage FCs, or simply components. These components represent the resources of the device attached to the Physical Entities of interest. The Application FG contains either standalone applications (e.g. for iOS, Android, Windows phone), or Business Applications that connect the IoT system to an Enterprise system. 4.2) Communication functional group The Hop-by-Hop Communication is applicable in the case that devices and messages have to traverse the mesh from node-to-node (hop-by-hop) until they reach a gateway node which forwards the message (if needed) further to the Internet. This FC has two main interfaces: one “southbound” to/from the actual radio on the device, and one “northbound” to/from the Network FC in the Communication FG. The Network FC is responsible for message routing & forwarding and the necessary translations of various identifiers and addresses. The translations can be (a) Between network layer identifiers to MAC and/or physical network identifiers, (b) Between high-level human readable host/node identifiers to network layer addresses and (c) Translation between node/service identifiers and network locators in case the higher layers above the networking layer use node or service identifiers The End-to-End Communication FC is responsible for end-to-end transport of application layer messages through diverse network and MAC/PHY layers. 4.3) IoT Service functional group The IoT Service FC is a collection of service implementations, which interface the related and associated Resources. For a Sensor type of a Resource, the IoT Service FC includes Services that receive requests from a User and returns the Sensor Resource value in synchronous or asynchronous (e.g. subscription/notification) fashion. The IoT Service Resolution FC contains the necessary functions to realize a directory of IoT Services that allows dynamic management of IoT Service descriptions and discovery/lookup/resolution of IoT Services by other Active Digital Artifacts. 4.4) Virtual Entity functional group: The Virtual Entity FG contains functions that support the interactions between Users and Physical Things through Virtual Entity services. An example of such an interaction is the query to an IoT system of the form, “What is the temperature in the conference room Titan?” 4.5) Process Management functional group: The IoT Process Management FG, integration of business processes with IoT-related services. It consists of two FCs: The Process Modelling FC provides that right tools for modelling a business process that utilises IoT-related services. The Process Execution FC contains the execution environment of the process models created by the Process Modelling FC and executes the created processes by utilising the Service Organisation FG in order to resolve high-level application requirements to specific IoT services 4.6) Service Organization functional group: The Service Composition FC manages the descriptions and execution environment of complex services consisting of simpler dependent services. An example of a complex composed service is a service offering the average of the values coming from a number of simple Sensor Services. The Service Orchestration FC resolves the requests coming from IoT Process Execution FC or User into the concrete IoT services that fulfill the requirements. The Service Choreography FC is a broker for facilitating communication among Services using the Publish/Subscribe pattern. Users and Services interested in specific IoT-related services subscribe to the Choreography FC, providing the desirable service attributes even if the desired services do not exist. 4.7) Security functional group: The Security FG contains the necessary functions for ensuring the security and privacy of an IoT system. The Identity Management FC manages the different identities of the involved Services or Users in an IoT system The The Authentication FC verifies the identity of a User and creates an assertion upon successful verification. Verifies the identity of a User and creates an assertion upon successful verification. The Authorization FC manages and enforces access control policies. It provides services to manage policies (CUD), as well as taking decisions and enforcing them regarding access rights of restricted resources. The Key Exchange & Management is used for setting up the necessary security keys between two communicating entities in an IoT system. The Trust & Reputation FC manages reputation scores of different interacting entities in an IoT system and calculates the service trust levels. 4.8) Management functional group: The Configuration FC maintains the configuration of the FCs and the Devices in an IoT system. The component collects the current configuration of all the FCs and devices, stores it in a historical database, and compares current and historical configurations. The Fault FC detects, logs, isolates, and corrects system-wide faults if possible. This means that individual component fault reporting triggers fault diagnosis and fault recovery procedures in the Fault FC. The component collects the current configuration of all the FCs and devices, stores it in a historical database, and compares current and historical configurations. The Member FC manages membership information about the relevant entities in an IoT system. The State FC is similar to the Configuration FC, and collects and logs state information from the current FCs, which can be used for fault diagnosis, performance analysis and prediction, as well as billing purposes. The Reporting FC is responsible for producing compressed reports about the system state based on input from FCs. ii-font-family. 5) Information view: The information view consists of (a) The description of the information handled in the IoT System, and (b) The way this information is handled in the system; in other words, the information lifecycle and flow (how information is created, processed, and deleted), and the information handling components Information description The pieces of information handled by an IoT system complying to an ARM such as the IoT-Architecture are the following:  Virtual Entity context information, i.e. the attributes (simple or complex) as represented by parts of the IoT Information model (attributes that have values and metadata such as the temperature of a room).This is one of the most important pieces of information that should be captured by an IoT system, and represents the properties of the associated Physical Entities or Things. IoT Service output itself is another important part of information generated by an IoT system. For example, this is the information generated by interrogating a Sensor or a Tag Service. Virtual Entity descriptions in general, which contain not only the attributes coming from IoT Devices (e.g. ownership information), but also associations between Virtual Entities and related IoT Services. IoT Service Descriptions, which contain associated Resources, interface descriptions, etc. Resource Descriptions, which contain the type of resource (e.g. sensor), identity, associated Services, and Devices. Device Descriptions such as device capabilities (e.g. sensors, radios). Descriptions of Composed Services, which contain the model of how a complex service is composed of simpler services. IoT Business Process Model, which describes the steps of a business process utilizing other IoT-related services (IoT, Virtual Entity,Composed Services). Security information such as keys, identity pools, policies, trust models, reputation scores, etc. Management information such as state information from operational FCs used for fault/performance purposes, membership information, etc.  Fig: Information exchange patterns Push: An FC A pushes the information to another FC B provided that the contact information of the component B is already configured in component A, and component B listens for such information pushes. Request/Response: An FC A sends a request to another FC B and receives a response from B after A serves the request. Typically the interaction is synchronous inthe sense that A must wait for a response from B before proceeding to other tasks, but in practice this limitation can be realized with parts of component A waiting, and other parts performing other tasks. Component B may need to handle concurrent requests and responses from multiple components, which imposes certain requirements on the capabilities for the device or the network that hosts the FC. Subscribe/Notify: Multiple subscriber components (SA, SB) can subscribe for information to a component C, and C will notify the relevant subscribers when the requested information is ready. This is typically an asynchronous information request after which each subscriber can perform other tasks. Nevertheless, a subscriber needs to have some listening components for receiving the asynchronous response. The target component C also needs to maintain state information about which subscribers requested which information and their contact information. The Subscribe/Notify pattern is applicable when typically one component is the host of the information needed by multiple other components. Then the subscribers need only establish a Subscribe/Notify relationship with one component. If multiple components can be information producers or information hosts, the Publish/Subscribe pattern is a more scalable solution from the point of view of the subscribers. Publish/Subscribe: In the Publish/Subscribe (also known as a Pub/Sub pattern), there is a third component called the broker B, which mediates subscription and publications between subscribers (information consumers) and publishers (or information producers). Subscribers such as SA and SB subscribe to the broker about the information they are interested in by describing the different properties of the information. Publishers publish information and metadata to the broker, and the broker pushes the published information to (notification) the subscribers whose interests match the published information. Following fig shows Information Flow and Lifecycle Use case to depict all views: Fig: Parking Lot Deployment and Operational View, Devices. The Deployment and Operational View depends on the specific actual use case and requirements, and therefore we present here one way of realizing the Parking Lot example seen earlier. Figure depicts the Devices view as Physical Entities deployed in the parking lot, as well as the occupancy sign. There are two sensor nodes (#1 and #2), each of which are connected to eight metal/car presence sensors. The two sensor nodes are connected to the payment station through wireless or wired communication. The payment station acts both as a user interface for the driver to pay and get a payment receipt as well as a communication gateway that connects the two sensor nodes and the payment interface physical devices (displays, credit card slots, coin/note input/output, etc.) with the Internet through Wide Area Network(WAN) technology. The occupancy sign also acts as a communication gateway for the actuator node (display of free parking spots), and we assume that because of the deployment, a direct connection to the payment station is not feasible (e.g. wired connectivity is too prohibitive to be deployed or sensitive to vandalism). The physical gateway devices connect through a WAN technology to the Internet and towards a data center where the parking lot management system software is hosted as one of the virtual machines on a Platform as a Service (PaaS;) configuration. The two main applications connected to this management system are human user mobile phone applications and parking operation center applications. We assume that the parking operation center manages several other parking lots using similar physical and virtual infrastructure.  Figure shows two views super imposed, the deployment and functional views, for the parking lot example. Please note that several FGs and FCs are omitted here for simplicity purposes, and certain non- IoT-specific Services appear in the figure because an IoT system is typically part of a larger system. Starting from the Sensor Devices, as seen earlier, Sensor Node #1 hosts Resource #11#18, representing the sensors for the parking spots #01#08, while earlier Sensor Node #2 hosts Resource #21#28, representing the sensors for the parking spots#09#16 Fig: Parking Lot Deployment & Operational View, Resources, Services, Virtual Entities, Users Assume that the sensor nodes are powerful enough to host the IoT Services #11#18 and #21#28 representing the respective resources. The two sensor nodes are connected to the gateway device that also hosts the payment service with the accompanying sensors and actuators, as seen earlier. The other gateway device hosts the occupancy sign actuator resource and corresponding service. The management system for the specific parking lot, as well as others, is deployed on a virtual machine on a data center. The virtual machine hosts communication capabilities, Virtual Entity services for the parking spots #01#16, the Virtual Entity services for the occupancy sign, a payment business process that involves the payment station and input from the occupancy sensor services, and the parking lot management service that provides exposure and access control to the parking lot occupancy data for the parking operation center and the consumer phone applications. As a reminder, the Virtual Entity service of the parking lot uses the IoT Services hosted on two sensor nodes and performs the mapping between the sensor node identifiers (#11#18 and #21#28) to parking spot identifiers (spot #01#16). The services offered on these parking spots are to read the current state of the parking spot to see whether it is “free” or “occupied.” The Virtual Entity corresponding to the occupancy sign contains one writable attribute: the number of free parking spots. A User writing this Virtual Entity attribute results in an actuator command to the real actuator resource to change its display to the new value.  Fig: Mapping IoT Domain Model concepts to Deployment View Figure shows an example of mapping an IoT Domain Model and Functional View to Devices with different capabilities (different alternatives) connecting to a cloud infrastructure. Alternative 1 shows devices that can host only a simple Sensor Device and a short-range wired or wireless connectivity technology (Basic Device #1). Such kind of device needs an Advanced Device of type #1 that allows the basic device to perform protocol adaptation (at least from the short-range wired or wireless connectivity technology to a WAN technology) so that the Sensor IoT service in the cloud and the Sensor Resource on the Basic Device #1 can exchange information. The Virtual Entity representing the Physical Entity where the Basic Device #1 is deployed is also hosted in the cloud. In alternative 2, Advanced Devices (type #2) can host the Sensor IoT Service communicating to the Sensor Resource on a Basic Device #1. The cloud infrastructure in this case only hosts the Virtual Entity Service corresponding to the Sensor IoT Service. The difference between alternative 1 and 2 is that the Sensor IoT Service hosted on an Advanced Device #2 should be capable of responding to requests from Users (cloud services, Applications) with the appropriate secure mediation of course. In alternative 3, the Basic Device #3 is capable of providing the Sensor Resource and the Sensor IoT Service but still needs an Advanced Device #1 to transport IoT service requests/responses/subscriptions/ notifications/publications to the Users in the cloud. According to experience, this kind of deployment scenario imposes a high burden on a Basic Device, which potentially makes the Basic Device the weakest link in the information flow, If malicious Users launch a Denial of Service (DoS) attack on the node, the probability of the node going down is very high. Alternatives 4 and 5 show Advanced Devices offering a WAN interface. In alternative 4, only the Sensor Resource is hosted on the Device, while in alternative 5, even the IoT Service is hosted on the Device. The Virtual Entity Service is hosted in the cloud. Real-World Design Constraints: The real world design constraints are mostly applied to devices and network components. It’s classified into two types:- Design Constraints 1) Functional Constraints 2) Non-Functional Constraints: 1) Technical constraints 2) Non-Technical constraints 1) Functional Constraints: Functional design constraints in IoT refer to the specific requirements and limitations that govern the functionality and operation of IoT systems. Here are some common functional design constraints in IoT: - Specific sensing and actuating capabilities: Sensing principle and data requirements: Sometimes continuous sampling of sensing data is required. For some applications, sampling after specific intervals is required. The parameters like higher network throughput, data loss, energy use, etc are decided based on sensing principle. The sensing field is to be considered for sensing in local area or distributed sensing. The distance between sensing points is also important factor to be considered. The physical environment has an implication on the communications technologies selected and the reliability of the system in operation thereafter. Devices must be placed in close enough proximity to communicate. Where the distance is too great, routing devices may be necessary. -Programming and embedded intelligence: Devices in the IoT are heterogeneous such as various computational architectures, including MCUs (8-, 16-,32- bit, ARM, 8051, RISC, Intel, etc.), signal conditioning (e.g. ADC), and memory (ROM, S/F/D) RAM, etc.), communications media, peripheral components (sensors, actuators, buttons, screens, LEDs), etc. In every case, an application programmer must consider the hardware selected or designed, and its capabilities. Application-level logic decides the sampling rate of the sensor, the local processing performed on sensor readings, the transmission schedule (or reporting rate), and the management of the communications protocol stack, among other things. The programmers have to reconfigure and reprogram devices in case of change in devices in IoT application. - Data Collection and Processing: IoT systems need to efficiently collect and process data from a variety of sensors and devices. Design constraints include defining the types of data to be collected, determining the frequency and volume of data, and establishing the processing requirements for real-time or batch processing. -Gateway: Gateway devices or proxies are selected according to need of data transitions. - Device Compatibility: IoT systems often involve multiple devices from different manufacturers with varying communication protocols and data formats. Design constraints include ensuring device compatibility, defining communication standards or protocols, and establishing mechanisms for device discovery, registration, and integration. 2) Non-Functional Constraints: Non functional constraints are having two types: 1) Technical constraints 2) Non-Technical constraints 1) Technical constraints: Technical constraints in IoT refer to the limitations and considerations related to the underlying technology and infrastructure of IoT systems. These constraints impact the design, implementation, and performance of IoT solutions. Here are some common technical constraints in IoT: - Network Bandwidth: IoT devices generate and transmit large amounts of data, which can strain network bandwidth. Technical constraints include the availability and capacity of the network infrastructure to handle data traffic efficiently and ensure timely delivery of data. - Security and Privacy: IoT systems face significant security and privacy challenges due to the large attack surface and potential vulnerabilities of connected devices. Technical constraints involve implementing robust security measures, including authentication, encryption, secure communication protocols, and intrusion detection systems, to protect data and devices from unauthorized access and attacks. -Connectivity: IoT devices require reliable and secure connectivity to transmit data to the cloud or other systems. Design constraints include determining the connectivity requirements (e.g., Wi-Fi, cellular, LPWAN), ensuring network coverage and quality, and establishing mechanisms for seamless and robust communication. - Interoperability: IoT devices come from different manufacturers and may use various communication protocols and data formats. The architecture should support interoperability by providing mechanisms to integrate heterogeneous devices and systems seamlessly. -Integration with existing systems: IoT systems must be able to integrate with existing systems, such as enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, and supply chain management (SCM) systems. This requires the use of common interfaces and protocols. -Maintenance and repair: IoT devices may be deployed in remote or hard-to-reach areas, where maintenance and repair may be difficult. This constraint must be considered during the design phase to ensure that the devices can be easily maintained and repaired, or that they have failover mechanisms in place to ensure continuity of service. 2) Non-Technical Constraints: -Legal and regulatory compliance: IoT deployments must adhere to various laws and regulations, including consumer protection, data privacy, security, and product safety. Complying with legal requirements and industry standards is a non-negotiable constraint that must be considered during the design and implementation phases. -Cultural and social factors: IoT systems may encounter cultural or social barriers that can impact user acceptance and adoption. Factors like cultural norms, language barriers, and accessibility requirements must be considered to design inclusive IoT solutions that cater to diverse user needs. -Interoperability and standardization: IoT involves a multitude of devices, platforms, and communication protocols. Interoperability challenges can arise due to the lack of standardized interfaces and protocols. Ensuring compatibility and interoperability between different IoT devices and systems is a non-technical constraint that needs to be addressed to facilitate seamless integration. -Cost: IoT devices must be designed to be cost-effective, as they are often deployed in large numbers. This requires the use of low-cost components, efficient manufacturing processes, and streamlined supply chains. -Ethical considerations: IoT devices and systems can raise ethical concerns, particularly regarding issues like surveillance, consent, and data ownership. Designing IoT systems that respect ethical principles and prioritize the well-being and autonomy of individuals is a significant constraint. -Social acceptance and trust: Widespread adoption of IoT technologies depends on public acceptance and trust. Concerns regarding privacy, security, and the potential impact on employment or societal structures must be addressed to gain public trust and ensure social acceptance. -Business models and economic viability: Developing sustainable business models for IoT solutions is crucial. The cost of devices, infrastructure, maintenance, and connectivity must be balanced with potential revenue streams and return on investment (ROI). Understanding the economic viability and ensuring scalability is a non-technical constraint that influences IoT implementation.