��Module-4��IoT Platforms Design Methodology�Chapter 5.1 -5.2 and 5.3 case study(optional)��

�IoT Platforms Design Methodology�

Introduction

IoT System Overview

• IoT systems consist of multiple components and deployment tiers. In the previous modules, we have discussed six IoT system levels.
• Each level is suited for different applications and has different components and deployment configurations.

Complexity in Design

• Designing IoT systems can be a complex and challenging task as these systems involve interactions between various components such as IoT devices and network resources, web services, analytics components, applications, and database servers.

​

Design Challenges

• Due to a wide range of choices available for each of these components, IoT system designers may find it difficult to evaluate the available alternatives.

Introduction

Design Challenges contd..

• loT system designers often tend to design IoT systems keeping specific products/services in mind.
• These designs are tied to specific product/service choices made. This leads to product, service or vendor lock-in, which while satisfactory to the dominant vendor, is unacceptable to the customer.
• For such systems, updating the system design to add new features or replacing a particular product/service choice for a component becomes very complex, and in many cases may require complete re-design of the system.

Introduction

Proposed IoT Design Methodology

• It is proposed in this Chapter, a generic design methodology for IoT system design which is independent of specific product, service or programming language.
• IoT systems designed with the proposed methodology have reduced design, testing and maintenance time, better interoperability and reduced complexity.
• With the proposed methodology, loT system designers can compare various alternatives for the loT system components.
• The methodology described in this Chapter is generally based on the IoT-A reference model, but is broad enough to embrace other industry efforts as well.

​

loT Design Methodology

• Figure shows the steps involved in the IoT system design methodology.
• Each of these steps is explained in the sections that follow.
• To explain these steps, we use the example of a smart IoT-based home automation system.

​

Figure 5.1: Steps involved in IoT system design methodology

IoT Design Methodology – Smart Home Automation Example

Introduction & Overview

• IoT Design Methodology offers a structured approach to build reliable, scalable, and vendor-independent IoT systems.

​

The 10 design steps are:

​

1. Purpose & Requirements

2. Process Model

3. Domain Model

4. Information Model

5. Service Specification

6. IoT Level

7. Functional View

8. Operational View

9. Integration

10. Application Development.

Physical vs Virtual Entities in IoT Design

Conceptual Difference

​

An IoT system models every real-world object (the Physical Entity) with a corresponding digital representation called a Virtual Entity. The Physical Entity exists in the tangible world and interacts with the environment, while the Virtual Entity mirrors its state, stores data, and enables monitoring or control through software.

Physical vs Virtual Entity – Comparison Table

How Physical and Virtual Entities Interact

​

In Smart Home Automation, the Physical Entity (Light bulb) connects through Raspberry Pi hardware. The Pi reads data from the LDR sensor and executes control commands on the bulb using a relay. Meanwhile, its Virtual Entity (Light_VE) in software stores the bulb’s current state ('ON' or 'OFF'). When the user switches the light from the web interface, the Virtual Entity updates first, sending the instruction to the Physical Entity. Similarly, when the sensor detects darkness, the Controller updates the Virtual Entity before toggling the real bulb. This continuous synchronization ensures that digital and physical realities remain consistent.

Key Summary

Steps 1–3

Steps 4–6: Data and System Structuring

Steps 7–9: Functional, Operational & Integration Views

Step 10 & Summary

Step 1: Purpose & Requirements Specification

​

• Every IoT project begins with understanding the purpose—why the system exists and what value it provides. In this phase, designers define the functional and non-functional requirements, user needs, and operational boundaries. The purpose acts as the anchor for all design decisions, ensuring alignment with real-world needs.
• For example, in a smart home automation system, the goal might be to control lighting remotely through a web interface. Requirements could include local data analysis, remote accessibility, automatic/manual control modes, and user authentication. By defining these early, developers avoid feature creep and ensure clarity of system objectives.
• This step creates the foundation for all subsequent stages. Each following step traces back to these initial requirements, guaranteeing that design decisions remain purpose-driven rather than technology-driven.

Step 2: Process Model Specification

​

• Once the purpose is established, designers model how the system will behave. The process model represents system activities, decisions, and transitions. It often uses flow diagrams where circles indicate start points, rectangles show actions, and diamonds depict decisions.
• In the smart home example, two main modes exist: Auto and Manual. In Auto mode, the system uses a light sensor to detect brightness and toggle the light automatically. In Manual mode, the user controls the light through a web interface. Each process is clearly mapped to ensure predictable behavior.
• This specification helps identify all possible states and transitions. It also forms the basis for service creation later, ensuring that every process is traceable and executable.

Step 3: Domain Model Specification

​

• The domain model abstracts the real-world entities, defining how physical and virtual components relate. It helps the designer visualize all tangible and digital objects that will participate in the system.
• In our example, Physical Entities include the room and the light appliance, while their Virtual Entities are digital representations used for control and monitoring. Devices (like Raspberry Pi), Resources (like the operating system or database), and Services (like control APIs) are also defined here.
• This step bridges the conceptual and physical layers. By clearly mapping entities, designers ensure modularity, easier maintenance, and seamless interoperability across the IoT ecosystem.

Step 4: Information Model Specification

​

• Information modeling defines the structure, attributes, and relationships of data in the system. It specifies what information each entity holds and how it interacts with others, independent of data storage technologies.
• In the home automation system, the Room entity may hold attributes like light_level, and the Light entity may hold light_state. This clear structure ensures consistency across applications, databases, and APIs.
• The information model is critical because it standardizes how data flows between layers, enabling integration, analytics, and future scalability without redesigning the system’s core data model.

Step 5: Service Specifications

​

• Here, designers derive services from process and information models. Each service performs a specific action—either modifying or retrieving system states.
• For example, the Mode Service controls whether the system operates in Auto or Manual mode, while the State Service controls the light’s on/off status. The Controller Service runs natively on the device, monitoring sensor data and executing control logic.
• Each service is defined with input/output parameters, REST endpoints, and security policies. This ensures the entire IoT system functions as a coordinated network of services, maintaining modularity and reusability.

Step 6: IoT Level Specification

​

• IoT levels define how computation, control, and data storage are distributed. Systems can range from Level-1 (fully local) to Level-5 (cloud-integrated and large-scale).
• The smart home system operates at Level-1, meaning all operations—sensor readings, decision-making, and actuation—occur locally within the home network. This allows for fast response times and independence from internet connectivity.
• Choosing the right level ensures system scalability and reliability. Designers evaluate latency, cost, and data privacy to assign an appropriate IoT level.

Step 7: Functional View Specification

​

• This step groups system functionalities into Functional Groups (FGs) based on their purpose and role. These include Device FG, Communication FG, Service FG, Management FG, Security FG, and Application FG.
• In the smart home case, sensors and actuators belong to the Device FG; Wi-Fi and TCP/IP protocols form the Communication FG; REST services make up the Service FG; and the web app belongs to the Application FG. Management and Security handle configuration and protection.
• This grouping improves modularity, allowing independent development, testing, and scaling of each functional block without impacting others.

Step 8: Operational View Specification

​

• The operational view translates abstract functional groups into real implementation details. It defines specific technologies, software frameworks, hosting models, and communication protocols.
• For the home automation system, Raspberry Pi acts as the computing device; Django REST Framework provides service endpoints; MySQL manages data; and HTTP over Wi-Fi serves as the communication backbone. Authentication and authorization policies are also established here.
• This step ensures that every design decision is technically feasible, secure, and consistent with previously defined requirements.

Step 9: Device & Component Integration

​

• Once all design components are finalized, physical and logical integration begins. Here, sensors, actuators, controllers, and software modules are connected and tested together.
• In our case, the LDR sensor connects to the Raspberry Pi to measure light levels, while a relay switch controls the lamp. The system runs Python-based services and communicates with a local web app and database.
• This integration phase verifies end-to-end functionality, ensuring smooth interaction between hardware and software before deployment.

Step 10: Application Development

​

• The final step focuses on building the user interface and overall application experience. The web or mobile application allows users to control and monitor IoT devices through a simple interface.
• In the home automation example, users can switch between Auto and Manual modes, toggle lights, and view current status updates in real time. The UI reflects the live state of the system and disables controls when automation is active.
• This step completes the journey from concept to implementation, ensuring that all functionalities are accessible, reliable, and user-friendly.

Summary and Flow

​

• The IoT Design Methodology provides a structured, vendor-independent path from system concept to real-world implementation. Each step builds upon the previous, ensuring that design decisions are logical, scalable, and maintainable.
• Through the Smart Home Automation example, we see how requirements evolve into processes, models, services, and ultimately, a functional IoT application. This methodology promotes reusability, interoperability, and long-term adaptability in any IoT domain.

loT Design Methodology

• The first step in IoT system design methodology is to define the purpose and requirements of the system.
• In this step, the system purpose, behavior and requirements (such as data collection requirements, data analysis requirements, system management requirements, data privacy and security requirements, user interface requirements, ……..) are captured.

​

Applying this to our example of a smart home automation system, the purpose and requirements for the system may be described as follows:

• Purpose : A home automation system that allows controlling of the lights in a home remotely using a web application.

​

Step 1: Purpose & Requirements Specification

loT Design Methodology

• Behavior : The home automation system should have auto and manual modes.
• In auto mode, the system measures the light level in the room and switches on the light when it gets dark.
• In manual mode, the system provides the option of manually and remotely switching on/off the light.
• System Management Requirement : The system should provide remote monitoring and control functions
• Data Analysis Requirement : The system should perform local analysis of the data.
• Application Deployment Requirement : The application should be deployed locally on the device, but should be accessible remotely.
• Security Requirement: The system should have basic user authentication capability.

​

loT Design Methodology

• The second step in the IoT design methodology is to define the process specification.
• In this step, the use cases of the IoT system are formally described based on and derived from the purpose and requirement specifications.
• Figure shows the process diagram for the home automation system.
• The process diagram shows the two modes of the system: auto and manual.
• In a process diagram, the circle denotes the start of a process, diamond denotes a decision box and rectangle denotes a state or attribute.

Step 2: Process Specification

Figure 5.2: Process specification for home automation IoT system

loT Design Methodology

• When the auto mode is chosen, the system monitors the light level.
• If the light level is low, the system changes the state of the light to “on”.
• Whereas, if the light level is high, the system changes the state of the light to “off”.
• When the manual mode is chosen, the system checks the light state set by the user.
• If the light state set by the user is “on”, the system changes the state of light to “on”.
• Whereas, if the light state set by the user is “‘off”, the system changes the state of light to “off”.

Figure 5.2: Process specification for home automation IoT system

Understanding the Process Specification Diagram

​

• The second step in the IoT Design Methodology is the Process Specification, which defines how the IoT system behaves during operation. It represents the logic and decisions that the system follows, forming a bridge between the abstract requirements and the concrete design steps that come later.
• Imagine you have already defined the goal of your smart home system—to control lights automatically or manually. Now, you need to define how it behaves under both conditions. The process specification is like writing a story that describes the sequence of actions the system will perform in different situations.

​

• The process diagram acts as a roadmap showing decisions and outcomes. The circle marks the starting point, diamonds represent decisions, and rectangles denote actions or system states. The system begins by checking its 'Mode'—if Auto is selected, it follows one branch; if Manual, it follows another. This ensures the system knows whether to act on its own or wait for user input.
• Thus, this diagram provides clarity on how the IoT system transitions between different states. It ensures that the automation logic is transparent, traceable, and testable before moving into actual implementation.

Story Flow: Auto Mode vs Manual Mode

​

• Once the system mode is chosen, the story unfolds along two parallel paths — Auto Mode and Manual Mode. These two modes demonstrate how the system balances intelligence and human control.
• In Auto Mode, the IoT system behaves like a smart assistant. It continuously monitors the environment using a Light Dependent Resistor (LDR). If the light level is low, meaning the room is dark, the system automatically turns the light ON. If the light level is high, indicating sufficient brightness, it turns the light OFF. This shows autonomous decision-making, where the system senses, decides, and acts without human intervention.

• In contrast, Manual Mode puts the user back in control. The system stops relying on sensor readings and waits for user input through a web or mobile app. If the user sets the light state to ON, the system switches the light ON. If the user sets it to OFF, it turns the light OFF. This mode gives flexibility, allowing the user to override automation, for example, to keep lights on for cleaning or maintenance even during the day.
• Together, these two modes represent the dual nature of IoT systems: automation guided by intelligence, and manual control guided by human intention. This combination ensures that the system is efficient, adaptable, and user-friendly — the ideal balance for real-world IoT design.

​

Connecting the Logic: Structure and Behavior

​

• The first slide introduces the process structure — showing how the IoT system’s logic is organized into decision and action flows. It acts as the architectural backbone that defines how the system will behave conceptually.
• The second slide continues the story by demonstrating the real-world execution of that logic. It narrates how Auto Mode and Manual Mode operate in everyday scenarios, translating design diagrams into human-understandable actions.
• Together, these slides form a complete learning unit. Students and designers can now clearly visualize both the static blueprint (the diagram) and the dynamic behavior (the story). This storytelling approach bridges theoretical understanding with practical IoT system thinking.

loT Design Methodology

• The third step in the loT design methodology is to define the Domain Model.
• The domain model describes the main concepts, entities and objects in the domain of IoT system to be designed.
• Domain model defines the attributes of the objects and relationships between objects.
• Domain model provides an abstract representation of the concepts, objects and entities in the IoT domain, independent of any specific technology or platform.
• With the domain model, the loT system designers can get an understanding of the loT domain for which the system is to be designed.

Step 3: Domain Model Specification

loT Design Methodology

• Figure shows the domain model for the home automation system example.
• The entities, objects and concepts defined in the domain model include: Physical Entity, Virtual Entity, Device, Resource, Service

loT Design Methodology

Physical Entity :

• Physical Entity is a discrete and identifiable entity in the physical environment (e.g. a room, a light, an appliance, a car, etc.).
• The IoT system provides information about the Physical Entity (using sensors) or performs actuation upon the Physical Entity (e.g., switching on a light).
• In the home automation example, there are two Physical Entities involved - one is the room in the home (of which the lighting conditions are to be monitored) and the other is the light appliance to be controlled.

​

Virtual Entity :

• Virtual Entity is a representation of the Physical Entity in the digital world.
• For each Physical Entity, there is a Virtual Entity in the domain model.
• In the home automation example, there is one Virtual Entity for the room to be monitored, another for the appliance to be controlled.

loT Design Methodology

Device :

• Device provides a medium for interactions between Physical Entities and Virtual Entities.
• Devices are either attached to Physical Entities or placed near Physical Entities.
• Devices are used to gather information about Physical Entities (e.g., from sensors), perform actuation upon Physical Entities (e.g. using actuators) or used to identify Physical Entities (e.g., using tags).
• In the home automation example, the device is a single-board mini computer which has light sensor and actuator (relay switch) attached to it.

loT Design Methodology

Resource :

• Resources are software components which can be either "on-device" or "network-resources".
• On-device resources are hosted on the device and include software components that either provide information on or enable actuation upon the Physical Entity to which the device is attached.
• Network resources include the software components that are available in network (such as a database).
• In the home automation example, the on-device resource is the operating system that runs on the single-board mini computer.

loT Design Methodology

Service :

• Services provide an interface for interacting with the Physical Entity.
• Services access the resources hosted on the device or the network resources to obtain information about the Physical Entity or perform actuation upon the Physical Entity.
• In the home automation example, there are three services:
• a service that sets mode to auto or manual, or retrieves the current mode;
• a service that sets the light appliance state to on/off, or retrieves the current light state;
• a controller service that runs as a native service on the device.
• When in auto mode, the controller service monitors the light level and switches the light on/off and updates the status in the status database.
• When in manual mode, the controller service retrieves the current state from the database and switches the light on/off.
• The process of deriving the services from the process specification and information model is described in the later sections.

​

IoT Design Methodology – Step 3: Domain Model Specification

Detailed explanation and storytelling for Smart Home Automation example

Introduction – Building the Conceptual World

​

• After defining the process flow in Step 2, the designer now transitions from system behavior to structure. Step 3 — the Domain Model Specification — focuses on building the conceptual foundation of the IoT ecosystem.
• It defines the main entities, objects, and relationships within the system. The model is abstract and platform-independent, showing what exists and how elements interact before implementation.
• In the Smart Home Automation example, this model identifies all participants involved in controlling the light: Room, Light, Sensors, Raspberry Pi, Services, and the User. The domain model visualizes how these elements connect to create intelligent, responsive behavior.

Understanding the Domain Model Diagram

​

• The domain model diagram represents the digital and physical connections between system components. It highlights how each element interacts to create a seamless IoT experience.
• The User interacts with an Active Digital Artifact (the web app). The app communicates with the Service layer, which in turn connects to Virtual Entities representing real-world objects such as the Room and the Light Appliance.
• Devices like Raspberry Pi host Resources that interact with sensors and actuators. Network and on-device resources ensure smooth data exchange and operation. This interconnected web allows real-time updates and actions across all layers.

Physical Entity – The Real-World Characters

​

• A Physical Entity represents a tangible, real-world object that can be sensed or controlled by the IoT system.
• In the Smart Home Automation example, two Physical Entities exist: the Room (whose lighting level is monitored) and the Light Appliance (which is switched ON or OFF).
• The system observes or acts upon these entities using sensors and actuators. Think of the Room as the stage and the Light as the performer — the IoT system decides when the performer should act based on environmental lighting.

Virtual Entity – The Digital Twin

​

• Each Physical Entity has a corresponding Virtual Entity that acts as its digital twin. This entity mirrors the real object’s state and properties in the digital domain.
• For example, the Room’s Virtual Entity stores the 'light_level' attribute received from the LDR sensor, while the Appliance’s Virtual Entity holds the 'light_state' (ON/OFF).
• These Virtual Entities synchronize the digital and physical worlds, allowing software services and users to interact with real objects without direct hardware access.

Device – The Bridge Between Worlds

​

• A Device serves as the bridge between Physical and Virtual Entities, translating environmental data into digital information and executing actions in the physical world.
• In this case, the Raspberry Pi mini-computer is the Device. It connects to the LDR sensor (to measure light levels) and the Relay switch (to toggle the lamp).
• The Device is the system’s narrator — constantly observing the environment, updating the digital model, and enforcing decisions to keep the story coherent and responsive.

Resource – The Software Backbone

​

• Resources are software components that enable devices to function intelligently. They can exist on the device itself or on a network server.
• On-device resources include the operating system, middleware, or services running on the Raspberry Pi, while network resources include remote databases or APIs for storing sensor data and status information.
• Resources transform the hardware into a smart system capable of communicating, analyzing, and storing data efficiently.

Service – The Interface of Interaction

​

• Services act as the interaction layer between users, applications, and physical devices. They expose functionalities of devices and resources through structured APIs.
• In this home automation setup, three services are defined: the Mode Service (to set Auto or Manual), the State Service (to control light ON/OFF), and the Controller Service (to handle real-time logic).
• When in Auto Mode, the controller reads light levels and switches lights accordingly. In Manual Mode, it responds to user input, offering a perfect balance of automation and control.

Interpreting the Domain Model as a Story

​

• Viewed as a story, the domain model becomes a living ecosystem. The User sends a command via the App, which is interpreted by the Service layer and transmitted to the appropriate Virtual Entity.
• The Virtual Entity updates its status, and the Device enforces the change on the Physical Entity through actuators. Meanwhile, Resources ensure that data is logged and consistent throughout the process.
• This feedback loop keeps all components synchronized — making the system intelligent, adaptive, and self-aware.

Conclusion – Importance of Domain Model Specification

​

• The Domain Model Specification defines the ecosystem of an IoT system before physical implementation. It clarifies who exists, what they do, and how they interact.
• By mapping Physical Entities, Virtual Entities, Devices, Resources, and Services, designers ensure every component has a defined role and clear data flow.
• In the Smart Home Automation story, this model ensures intelligent lighting behavior — switching ON in darkness, responding instantly to user input, and maintaining digital-physical harmony. It is the backbone of a truly connected system.

loT Design Methodology

• The fourth step in the loT design methodology is to define the Information Model.
• Information Model defines the structure of all the information in the IoT system, for example, attributes of Virtual Entities, relations, etc.
• Information model does not describe the specifics of how the information is represented or stored.
• To define the information model, we first list the Virtual Entities defined in the Domain Model.
• Information model adds more details to the Virtual Entities by defining their attributes and relations.

Step 4: Information Model Specification

loT Design Methodology

• In the home automation example, there are two Virtual Entities - a Virtual Entity for the light appliance (with attribute - light state) and a Virtual Entity for the room (with attribute - light level).
• Figure shows the Information Model for the home automation system example.

Figure 5.4: Information model of the home automation IoT system

IoT Design Methodology – Step 4: Information Model Specification

Detailed explanation and storytelling for the Smart Home Automation example

Introduction – Defining the Information Model

​

• The fourth step in the IoT Design Methodology is to define the Information Model. While the Domain Model identifies the main entities, the Information Model defines the structure of data these entities contain.
• It specifies the attributes, relations, and information flow between Virtual Entities without describing how or where this data is stored. In essence, it captures the logical representation of information, acting as the blueprint for how data moves and changes within the IoT system.
• For our Smart Home Automation example, the Information Model connects the Room and Light Appliance Virtual Entities, showing how attributes like light-level and light-state are interlinked.

Virtual Entities and Their Attributes

​

• To define the Information Model, we begin with the Virtual Entities introduced in the Domain Model — here, the Room and the Light Appliance.
• Each Virtual Entity has specific attributes that describe its state. The Room entity includes an attribute called 'light-level,' and the Light Appliance entity includes an attribute called 'state.'
• These attributes give meaning to the Virtual Entities. They define what kind of data is associated with each object, making it possible for the IoT system to understand and interact with the physical world intelligently.

Storytelling – Information Model Diagram Explanation

​

• The figure of the Information Model represents two Virtual Entities: Room and Light Appliance. Both are digitally linked, indicating that the appliance exists within the room and interacts with it.
• The Room entity has an attribute 'Light-Level,' which can take values like 'High' or 'Low.' The Light Appliance entity has an attribute 'State,' which can be either 'On' or 'Off.'
• When the system detects that the Light-Level is 'Low,' it updates the Light Appliance’s State to 'On.' Similarly, if the Light-Level is 'High,' the system updates the State to 'Off.'
• This simple relationship forms the logical connection between environment sensing and device actuation, defining how data flows from one Virtual Entity to another.

Logical Flow and Relationships in the Information Model

​

• In the Information Model, relationships define how Virtual Entities interact through their attributes. These relationships are essential for enabling decision-making in IoT systems.
• In our example, the relationship 'in room' connects the Light Appliance to the Room entity, establishing a spatial and logical link between them.
• The attribute relationships, such as 'has light-level' or 'is in state,' describe how environmental data (light intensity) influences system actions (turning the light on or off). These connections make the system context-aware and adaptive.

Real-World Story – From Information to Action

​

• Let’s imagine the Smart Home system in action. A sensor continuously monitors the light intensity in the room. The Room’s Virtual Entity updates its attribute 'light-level' as 'Low.'
• This triggers the system to evaluate the Light Appliance entity’s state attribute. Recognizing that the light level is insufficient, the system sets the 'state' attribute to 'On,' activating the relay that powers the light.
• Later, when sunlight fills the room, the Room’s Virtual Entity changes 'light-level' to 'High.' The system responds automatically by setting the Light Appliance’s 'state' to 'Off.'
• This story demonstrates how the Information Model governs logical decisions in the IoT system, making the behavior intelligent, dynamic, and responsive.

Conclusion – Importance of the Information Model

​

• The Information Model Specification transforms abstract entities into meaningful digital structures. It ensures that every Virtual Entity has clearly defined attributes and relationships, enabling smooth data exchange within the IoT system.
• This model is crucial for linking sensors and actuators logically. It acts as a reference for developers to create databases, define APIs, and implement control algorithms.
• In the Smart Home Automation system, the Information Model provides the digital logic that determines how light-level data influences lighting behavior. It serves as the brain that connects sensing with actuation, completing the data-driven intelligence cycle.

loT Design Methodology

• The fifth step in the IoT design methodology is to define the service specifications.
• Service specifications define the services in the IoT system, service types, service inputs/output, service endpoints, service schedules, service preconditions and service effects.
• You learned about the Process Specification and Information Model in the previous sections.
• Figure shows an example of deriving the services from the process specification and information model for the home automation IoT system.

Step 5: Service Specifications

Figure 5.5: Deriving services from process specification and information model for home automation IoT system

loT Design Methodology

• From the process specification and information model, we identify the states and attributes.
• For each state and attribute we define a service.
• These services either change the state or attribute values or retrieve the current values.
• For example, the Mode service sets mode to auto or manual or retrieves the current mode.
• The State service sets the light appliance state to on/off or retrieves the current light state.

loT Design Methodology

• The Controller service monitors the light level in auto mode and switches the light on/off and updates the status in the status database.
• In manual mode, the controller service, retrieves the current state from the database and switches the light on/off.

Controller service of the home automation IoT system

Figure 5.6: Controller service of the home automation IoT system

loT Design Methodology Mode service

• The Mode service is a RESTful web service that sets mode to auto or manual (PUT request), or retrieves the current mode (GET request) .
• The mode is updated to/retrieved from the database.

Figure 5.7: Service specification for home automation IoT system - mode service

loT Design Methodology State Service

• The State service is a RESTful web service that sets the light appliance state to on/off (PUT request), or retrieves the current light state (GET request),
• The state is updated to/retrieved from the status database.

Figure 5.7: Service specification for home automation IoT system - state service

loT Design Methodology

• The Controller service runs as a native service on the device.
• When in auto mode, the controller service monitors the light level and switches the light on/off and updates the status in the status database.
• When in manual mode, the controller service, retrieves the current state from the database and switches the light on/off.

IoT Design Methodology – Step 5: Service Specifications

Detailed explanation and storytelling for the Smart Home Automation example

Introduction – Defining Service Specifications

​

• The fifth step in the IoT Design Methodology focuses on defining Service Specifications. Once the process and information models are complete, we identify specific services that handle data flow, device control, and communication.
• Service specifications describe the service types, their inputs and outputs, endpoints, and behavior under different conditions. They form the operational bridge between virtual and physical entities, ensuring smooth interaction among system components.
• In the Smart Home Automation example, three services are derived: Mode Service, State Service, and Controller Service.

Deriving Services from Process and Information Models

​

• Services are derived from the states and attributes identified in the Process and Information Models. Each attribute or state corresponds to a potential service operation.
• For example, from the Process Model, we identify decisions like Auto or Manual Mode and Light ON or OFF. From the Information Model, we recognize attributes such as 'light-level' and 'state.'
• Combining these insights helps define three key services: the Mode Service to manage system mode, the State Service to control light states, and the Controller Service to handle automated logic.
• This ensures that every part of the IoT system has a specific service managing its data and behavior in a standardized way.

Mode Service – Managing System Behavior

​

• The Mode Service is a RESTful web service that determines how the system operates — either automatically or manually. It interacts with the database to retrieve or update the current mode.
• When the user switches to Auto Mode, this service triggers the Controller Service to begin monitoring environmental data. In Manual Mode, it enables direct control through the web interface.
• Technically, this service handles HTTP GET requests to retrieve the current mode and PUT requests to change it. It ensures seamless transition between user-driven and automated operations.

State Service – Controlling the Light Appliance

​

• The State Service is responsible for managing the ON/OFF condition of the light appliance. It provides an interface for both automatic and manual control through RESTful APIs.
• In automatic control, the Controller Service updates this state based on the light level in the room. In manual control, the user changes it via the application.
• The service accepts HTTP PUT requests to update the light’s state and GET requests to read the current condition. The service endpoint communicates with a status database that reflects real-time system updates.
• This service ensures synchronization between digital commands and physical device states, maintaining system consistency.

Controller Service – The Core Automation Logic

​

• The Controller Service operates as a native service on the Raspberry Pi device. It functions as the brain of the IoT system, implementing decision logic based on sensor inputs and mode selection.
• In Auto Mode, it continuously reads light levels from the sensor every few seconds. If the light level is low, it updates the State Service to turn the light ON; if high, it turns it OFF.
• In Manual Mode, it retrieves the state from the database and executes commands according to user input. This service ensures the system remains responsive and autonomous.
• By running locally, it minimizes latency, ensuring that environmental changes are detected and acted upon in real-time.

Storytelling – How Services Interact

​

• Imagine you walk into your home at dusk. The system detects that the room’s light level is low through the sensor. The Controller Service processes this data and sends a request to the State Service to turn ON the light.
• The Mode Service confirms the system is in Auto Mode and allows the Controller Service to operate. The light turns ON automatically.
• Later, if you decide to manually switch the lights OFF, you use the app interface. The Mode Service changes to Manual Mode, pausing automatic control. The State Service executes your command immediately.
• This flow illustrates how the three services — Mode, State, and Controller — cooperate harmoniously, ensuring that both human intent and environmental conditions are respected in real-time.

Conclusion – Role of Services in IoT Design

​

• Service Specifications form the backbone of any IoT system. They define how information and actions flow between users, devices, and applications.
• By deriving services from Process and Information Models, designers ensure logical consistency, scalability, and interoperability across all IoT layers.
• In the Smart Home Automation system, the Mode, State, and Controller Services together enable flexible, context-aware, and reliable operation. These services make the system more modular, easier to maintain, and adaptable to future enhancements.

loT Design Methodology

• The sixth step in the IoT design methodology is to define the IoT level for the system.
• In module1, we defined five loT deployment levels.
• Fig. shows the deployment level of the home automation IoT system, which is level-1.

Step 6: loT Level Specification

Figure 5.9: Deployment design of the home automation IoT system

IoT Design Methodology – Step 6: IoT Level Specification

Detailed explanation and storytelling for Smart Home Automation deployment design

Introduction – Understanding IoT Level Specification

​

• The sixth step in the IoT Design Methodology is to define the IoT Level Specification. This step determines how the IoT components are deployed across local and cloud infrastructure, defining the architecture’s scalability, performance, and data handling behavior.
• In the Smart Home Automation system, the deployment follows Level-1 — a localized IoT setup where all processing, decision-making, and communication occur within the local network. This ensures low latency and independence from the cloud.
• Higher levels, such as Level-2 and beyond, can extend this structure to cloud analytics, multi-home integration, and large-scale IoT ecosystems.

Local Level Architecture – The Edge Processing Zone

​

• At Level-1, the IoT system operates locally within a confined network. The local level houses key components like the Controller Service, Resources, Devices, and Database that interact seamlessly without cloud dependency.
• The Controller Service, hosted on a Raspberry Pi or similar device, processes sensor inputs and controls the actuators in real-time. Resources serve as the software layer connecting the Controller Service with the Device layer, which consists of physical components such as sensors (LDR) and actuators (relay switches).
• This edge-based design ensures real-time response — for example, instantly switching on a light when the room becomes dark — without waiting for internet communication.

REST Communication and Local Database Management

​

• Communication between the app and the IoT system happens through REST APIs. These APIs define clear interfaces that enable sending or receiving data such as current light state, mode status, and environmental readings.
• For example, when a user opens the mobile app and changes the mode from Manual to Auto, the app sends an HTTP PUT request to the REST Service. This update is stored in the Database and instantly applied by the Controller Service.
• The Database acts as the system’s memory, ensuring that all states — light-level, light-state, and mode — remain synchronized between devices and user interfaces.

Monitoring Node and Cloud Integration Possibility

​

• The Monitoring Node continuously collects data from sensors and logs operational metrics such as light status changes, environmental readings, and energy consumption.
• In Level-1, the Monitoring Node operates locally, ensuring real-time performance. However, this design is scalable — the data can later be transmitted to the cloud for long-term analytics, predictive modeling, or multi-device coordination.
• In higher IoT levels, such as Level-3 and beyond, cloud integration enables users to monitor and control their home devices remotely, allowing for advanced AI-based automation and predictive control features.
• This hybrid approach ensures flexibility — systems start locally for simplicity and expand to the cloud as intelligence and connectivity needs grow.

Storytelling – A Day with the Smart Home System

​

• Imagine you walk into your room at dusk. The LDR sensor detects that the light intensity has dropped below a threshold. The Controller Service immediately processes this input and updates the Database with the current light level ('Low').
• The system, operating in Auto Mode, consults the stored configuration and decides to turn ON the light. The Resource module sends a command to the Relay actuator in the Device layer, illuminating the room instantly.
• At the same time, your mobile app (connected via REST Communication) updates to display 'Light ON.' All this occurs within milliseconds — fully localized, secure, and efficient.
• If you later switch the system to Manual Mode, you can override automation. Every action you take is still stored locally in the Database, ensuring synchronization and traceability.

Conclusion – Importance of IoT Level Specification

​

• The IoT Level Specification provides clarity on how components are distributed across local and cloud systems. It influences system performance, scalability, and data management efficiency.
• Level-1 systems, like the Smart Home Automation setup, prioritize speed, reliability, and offline operation. As the system evolves, cloud integration can enhance analytics, monitoring, and global control capabilities.
• Thus, this step ensures a balanced architecture — one that starts simple and local but can evolve into a fully connected, intelligent IoT ecosystem as demands increase.

loT Design Methodology

• The seventh step in the IoT design methodology is to define the Functional View.
• The Functional View (FV) defines the functions of the loT systems grouped into various Functional Groups (FGs).
• Each Functional Group either provides functionalities for interacting with instances of concepts defined in the Domain Model or provides information related to these concepts.

​

The Functional Groups (FG) included in a Functional View include:

Device :

• The device FG contains devices for monitoring and control.
• In the home automation example, the device FG includes a single board mini-computer, a light sensor and a relay switch (actuator).

​

Step 7: Functional View Specification

loT Design Methodology

Communication :

• The communication FG handles the communication for the loT system.
• The communication FG includes the communication protocols that form the backbone of IoT systems and enable network connectivity.
• You learned about various link, network, transport and application layer protocols in module-1.
• The communication FG also includes the communication APIs (such as REST and WebSocket) that are used by the services and applications to exchange data over the network.
• In the home automation example the communication protocols include - 802.11 (link layer), IPv4/IPv6 (network layer), TCP (transport layer), and HTTP (application layer).
• The communication API used in the home automation examples is a REST-based API.

​

loT Design Methodology

Services :

• The service FG includes various services involved in the IoT system such as services for device monitoring, device control services, data publishing services and services for device discovery.
• In the home automation example, there are two REST services (mode and state service) and one native service (controller service).
• Management: The management FG includes all functionalities that are needed to configure and manage the IoT system.
• Security: The security FG includes security mechanisms for the IoT system such as authentication, authorization, data security, etc.
• Application: The application FG includes applications that provide an interface to the users to control and monitor various aspects of the loT system.
• Applications also allow users to view the system status and the processed data.

​

loT Design Methodology

• Fig. shows an example of mapping deployment level to functional groups for home automation IoT system.
• IoT device maps to the Device FG (sensors, actuators devices, computing devices) and the Management FG (device management).
• Resources map to the Device FG (on-device resource) and Communication FG (communication APIs and protocols).

loT Design Methodology

loT Design Methodology

• Controller service maps to the Services FG (native service).
• Web Services map to Services FG .
• Database maps to the Management FG (database management) and Security FG (database security).
• Application maps to the Application FG (web application, application and database servers), Management FG (app management) and Security FG (app security).

​

IoT Design Methodology – Step 7: Functional View Specification

Detailed explanation and storytelling for Smart Home Automation Functional Groups (FGs)

Introduction – Understanding Functional View Specification

​

• The seventh step in the IoT Design Methodology is to define the Functional View Specification (FV).
• The Functional View defines the various Functional Groups (FGs) that describe how system components interact, share data, and fulfill specific tasks within the IoT ecosystem.
• Each Functional Group provides a specific function — such as sensing, communication, service control, management, or security — and together they ensure that the system operates cohesively.
• In the Smart Home Automation example, the Functional View includes Device, Communication, Services, Management, Security, and Application groups.

Device Functional Group – The Physical Backbone

​

• The Device Functional Group (FG) includes all the physical devices responsible for monitoring and control operations.
• In the Smart Home Automation example, the Device FG includes a single-board mini-computer (such as a Raspberry Pi), a light sensor (LDR), and a relay actuator for switching the light.
• These devices form the system’s sensory and reactive layer. Sensors collect environmental data such as light intensity, while actuators perform actions like turning lights on or off.
• The Device FG acts as the hands and eyes of the IoT system — sensing the environment and performing actions based on system logic.

Communication Functional Group – The Network Enabler

​

• The Communication Functional Group (FG) handles all communication aspects of the IoT system. It enables connectivity between devices, services, and users.
• This FG includes the communication protocols and APIs used to transmit data reliably. It covers multiple OSI layers — link, network, transport, and application.
• In the home automation example, communication occurs through Wi-Fi (IEEE 802.11), IPv4/IPv6 (network layer), TCP (transport layer), and HTTP (application layer).
• RESTful APIs facilitate message exchange between the web application, controller service, and database. These APIs ensure seamless, real-time updates between devices and user interfaces.

Services Functional Group – The Operational Core

​

• The Services Functional Group includes all services that define how devices, applications, and users interact with each other.
• In the Smart Home Automation example, there are three key services: Mode Service, State Service, and Controller Service. These services collectively manage automation logic, control operations, and respond to environmental changes.
• Mode Service determines whether the system runs in Auto or Manual mode. State Service handles ON/OFF control of the light appliance. Controller Service coordinates between these to ensure real-time decision-making.
• This FG serves as the system’s brain, orchestrating all actions based on input data and user preferences.

Management, Security, and Application Functional Groups

​

• The Management FG handles system configuration, device registration, and overall monitoring of network operations. It ensures proper functioning and easy scalability of the IoT system.
• The Security FG manages authentication, authorization, and data protection, preventing unauthorized access and ensuring safe communication between devices and users.
• The Application FG represents the topmost layer where users interact with the system through dashboards, mobile apps, or web interfaces. It allows users to view status, send commands, and analyze performance metrics.
• Together, these FGs provide a balance between control, safety, and usability, ensuring that the system remains reliable and user-centric.

Mapping Deployment Level to Functional Groups

​

• The Functional View can be directly mapped to the IoT Level Specification to visualize how deployment components relate to functional responsibilities.
• For example, IoT devices such as sensors and actuators belong to the Device FG and Management FG. Resources belong to the Device FG and Communication FG.
• Web services, including REST APIs, belong to the Services FG. The Controller Service maps to both the Services FG and Management FG as it manages automation and device coordination.
• The Application layer connects to the Application FG and Security FG, ensuring secure user access and interaction. This mapping establishes clear functional boundaries for efficient IoT system design.

Storytelling – How Functional Groups Work Together

​

• Imagine waking up early in the morning. As sunlight enters your room, the LDR sensor (Device FG) detects a high light level and sends this information through the Communication FG using REST APIs.
• The Controller Service (Services FG) processes this data, updates the Database (Management FG), and turns the light OFF. The Security FG ensures that this action is authenticated and logged safely.
• Meanwhile, the mobile app (Application FG) reflects the light’s OFF status instantly, giving you a live update of system behavior. Each FG plays its part, synchronizing physical and digital worlds seamlessly.
• This demonstrates how the Functional View unites all layers of the IoT system into a coherent, intelligent network that senses, decides, and acts with precision.

Conclusion – Importance of Functional View Specification

​

• The Functional View Specification is essential for defining how different parts of an IoT system work together logically and operationally.
• By organizing system components into Functional Groups, designers achieve modularity, scalability, and better control over system performance.
• In the Smart Home Automation example, the interplay between Device, Communication, Services, Management, Security, and Application FGs ensures that every data flow and control operation happens efficiently and securely.
• Thus, the Functional View acts as a blueprint that connects technology with functionality, forming the foundation of robust IoT system architecture.

loT Design Methodology

• The eighth step in the IoT design methodology is to define the Operational View Specifications.
• In this step, various options pertaining to the IoT system deployment and operation are defined, such as, service hosting options, storage options, device options, application hosting options, etc.
• Fig. shows an example of mapping functional groups to operational view specifications for home automation IoT system.

Step 8: Operational View Specification

loT Design Methodology

Step 8: Operational View Specification

loT Design Methodology

• Operational View specifications for the home automation example are as follows:
• Devices: Computing device (Raspberry Pi), light dependent resistor (sensor), relay switch (actuator).
• Communication APIs: REST APIs
• Communication Protocols: Link Layer - 802.11, Network Layer - IPv4/IPv6, Transport - TCP, Application - HTTP.

loT Design Methodology

Services:

1. Controller Service - Hosted on device, implemented in Python and run as a native service.

2. Mode service - REST-ful web service, hosted on device, implemented with Django-REST Framework.

3. State service - REST-ful web service, hosted on device, implemented with Django-REST Framework.

​

Application:

• Web Application - Django Web Application,
• Application Server - Django App Server,
• Database Server - MySQL.

loT Design Methodology

Security:

• Authentication: Web App, Database
• Authorization: Web App, Database

​

Management:

• Application Management - Django App Management Database Management - MySQL DB Management,
• Device Management - Raspberry Pi device Management.

IoT Design Methodology – Step 8: Operational View Specification

Detailed explanation and storytelling for Smart Home Automation operational deployment

Introduction – Understanding Operational View Specification

​

• The eighth step in the IoT Design Methodology is to define the Operational View Specification. This step focuses on how the IoT system’s components are physically deployed, hosted, and managed for real-world operation.
• It defines key options like service hosting, storage mechanisms, device management, and application hosting. Essentially, it bridges the design and deployment phases, converting the abstract system model into an operational architecture.
• In the Smart Home Automation example, this step explains how devices, services, applications, and databases are integrated and hosted for smooth operation.

Devices and Communication Setup

​

• At the core of the Smart Home Automation system lies the Device layer. It includes:
• 1. Raspberry Pi – acts as the computing unit hosting native and RESTful services.
• 2. LDR Sensor – monitors the room’s light intensity and continuously sends readings to the Controller Service.
• 3. Relay Switch – functions as the actuator that controls the ON/OFF state of the light appliance.
• The Communication layer connects these devices using REST APIs over Wi-Fi (IEEE 802.11). Data travels across multiple layers: Link (802.11), Network (IPv4/IPv6), Transport (TCP), and Application (HTTP). This ensures reliable, real-time communication between sensors, controllers, and the web application.

Services Hosting – The System’s Operational Core

​

• Services form the operational backbone of the IoT system. In this example, there are three types of services:
• 1. Controller Service – implemented in Python, hosted on the Raspberry Pi, and acts as a native service that executes automation logic.
• 2. Mode Service – a RESTful web service that lets users switch between Auto and Manual modes using the Django REST Framework.
• 3. State Service – another RESTful web service that handles the light appliance’s ON/OFF control and state retrieval.
• These services run locally on the Raspberry Pi, ensuring minimal latency and continuous operation even without internet access.

Application and Database Hosting

​

• The Application layer provides the interface for users to monitor and control their home automation system. It includes:
• • Web Application: A Django-based web interface that displays current light states, mode selection, and historical data.
• • Application Server: Django App Server that processes REST API requests and coordinates data exchange between the app and database.
• • Database Server: A MySQL server that stores all system data, including user settings, sensor readings, and status logs.
• Together, these layers create an efficient, structured backend that supports fast data access, real-time updates, and a user-friendly interface.

Security and Management View

​

• The Security layer safeguards communication, authentication, and authorization. It ensures only verified users can control or monitor the system.
• • Authentication: Managed through Django Web App and Database credentials to validate users.
• • Authorization: Controls user permissions and defines access rights for mode switching and device control.
• The Management layer ensures smooth operation and maintenance:
• • Application Management: Django App Management for service deployment and monitoring.
• • Database Management: MySQL management tools for data handling and optimization.
• • Device Management: Raspberry Pi management for firmware updates and performance checks.
• These management strategies ensure that the IoT system remains operational, secure, and upgradable.

Storytelling – A Day in the Life of the IoT System

​

• Imagine it’s evening — the sun begins to set, and the light level in the room decreases. The LDR sensor detects this and sends a signal to the Controller Service hosted on the Raspberry Pi.
• The Controller Service processes this input and checks the current system mode from the MySQL database. Since the system is in Auto Mode, it triggers the State Service to turn ON the relay, activating the light.
• Simultaneously, the Django Web App updates the light’s status on the user dashboard. The RESTful APIs handle data transmission across the Communication layer in real-time.
• Throughout this process, the Security layer ensures that no unauthorized control occurs, and the Management layer monitors device health and logs operations for reliability.
• This operational view shows how every element — from hardware to software — functions in perfect synchrony to deliver a smooth, intelligent experience.

Conclusion – Importance of Operational View Specification

​

• The Operational View Specification transforms an IoT design from theory to practice. It defines where and how each component operates, ensuring system functionality and efficiency.
• In the Smart Home Automation system, every service, device, and database has a well-defined hosting and operational role. This structured deployment guarantees optimal performance and smooth communication between modules.
• By detailing device, service, and management operations, this step lays the foundation for real-time, reliable IoT performance, forming the bridge between design logic and live implementation.

loT Design Methodology

• The ninth step in the loT design methodology is the integration of the devices and components.
• Fig.shows a schematic diagram of the home automation IoT system.
• The devices and components used in this example are Raspberry Pi mini computer, LDR sensor and relay switch actuator.

​

Step 9: Device & Component Integration

IoT Design Methodology – Step 9: Device & Component Integration

Detailed explanation and storytelling for Smart Home Automation hardware integration

Introduction – Understanding Device & Component Integration

​

• The ninth step in the IoT Design Methodology focuses on integrating all physical devices and components to bring the system to life. This stage transitions the IoT design from digital planning to tangible implementation.
• In this Smart Home Automation example, the integration involves connecting sensors, actuators, and computing devices to work cohesively. The main components include a Raspberry Pi mini-computer, an LDR (Light Dependent Resistor) sensor, and a relay switch actuator controlling a light bulb.

Hardware Components and Their Roles

​

• Each hardware component in the setup has a distinct and critical role:
• 1. Raspberry Pi: Acts as the central processing unit, executing automation logic and hosting the Controller, Mode, and State services.
• 2. LDR Sensor: Monitors ambient light levels. It detects low light and sends analog signals to the Raspberry Pi’s GPIO pins for interpretation.
• 3. Relay Module: Serves as an actuator, switching the light bulb ON or OFF based on the command from the Raspberry Pi.
• The interconnection of these components forms a closed-loop system capable of sensing, processing, and acting autonomously.

Circuit Integration and Connections

​

• The schematic diagram shows how all components are interconnected using a breadboard for prototyping.
• The LDR sensor is connected to an analog-to-digital converter (ADC) since the Raspberry Pi’s GPIO pins handle digital signals only. This allows precise measurement of light intensity.
• The relay module’s input pin is linked to one of the Pi’s GPIO output pins. When the Pi outputs a HIGH signal, the relay energizes and closes its circuit, turning the connected light ON.
• A 5V power supply from the Raspberry Pi powers the sensor and relay, ensuring stable and safe operation within the breadboard prototype.

Software-Hardware Synchronization

​

• The integration doesn’t stop at physical wiring—it also involves software-level coordination between services and components.
• The Raspberry Pi runs Python scripts that interface with the hardware through GPIO libraries. These scripts continuously read LDR data and determine the light’s operational state.
• If the system mode is set to AUTO, the program automatically toggles the relay based on light intensity thresholds. In MANUAL mode, user commands from the web application override automatic control.
• This synchronization ensures seamless collaboration between hardware sensing and cloud-level decision-making.

Storytelling – A Practical Scenario

​

• Imagine a user sitting in their living room in the evening. As daylight fades, the LDR sensor detects decreasing light intensity. The Raspberry Pi processes this input through the Controller Service and sends a HIGH signal to the relay, turning the lamp ON automatically.
• Later, the user decides to switch to MANUAL mode via the Django Web App. A REST command is sent to the Pi, changing the mode and allowing direct control. The user can now toggle the light through their phone interface.
• This story demonstrates how physical integration paired with intelligent software creates a responsive, interactive home environment.

Importance of Device & Component Integration

​

• Device and component integration is the foundation of any IoT system—it ensures that sensors, actuators, and processing units function harmoniously.
• A properly integrated system enhances reliability, reduces response time, and minimizes errors in signal transmission.
• This integration stage transforms theoretical IoT designs into working prototypes capable of real-world automation and decision-making.
• In the Smart Home Automation example, this integration proves how a simple setup with minimal hardware can deliver efficient and intelligent control.

loT Design Methodology

• The final step in the loT design methodology is to develop the IoT application.
• Fig. shows a screenshot of the home automation web application.
• The application has controls for the mode (auto on or auto off) and the light (on or off).
• In the auto mode, the loT system controls the light appliance automatically based on the lighting conditions in the room.
• When auto mode is enabled the light control in the application is disabled and it reflects the current state of the light.
• When the auto mode is disabled, the light control is enabled and it is used for manually controlling the light.

​

Step 10: Application Development

IoT Design Methodology – Step 10: Application Development

Detailed explanation and storytelling for Smart Home Automation Application Design

Introduction – The Role of Application Development

​

• The final step in the IoT Design Methodology is the development of the IoT application — the user-facing interface that enables seamless interaction with the system.
• In the Smart Home Automation system, the web application allows the user to monitor and control the lighting system efficiently. It serves as the bridge between human input and machine actions, bringing automation under user control.
• This web application provides an intuitive dashboard for switching between Auto and Manual modes and for turning the light ON or OFF based on real-time sensor data.

Application Overview

​

• The home automation web application is developed using the Django framework and integrated with RESTful APIs that communicate with the Raspberry Pi.
• The dashboard, as shown in the figure, contains two primary controls:
• 1. Mode Control – Allows users to toggle between Auto Mode and Manual Mode.
• 2. Light Control – Allows users to manually switch the light ON or OFF when Auto Mode is disabled.
• When Auto Mode is active, the Light Control button becomes disabled, ensuring that the system takes control based on real-time light sensor readings.

Functional Workflow of the Application

​

• The functional workflow of the application ensures smooth data exchange between the frontend (user interface) and backend (IoT services).
• Step 1: The user interacts with the web dashboard, either switching between modes or controlling the light manually.
• Step 2: The web app sends HTTP requests (GET or PUT) via REST APIs to the Raspberry Pi’s Controller Service.
• Step 3: The Controller Service processes the request — in Auto Mode, it uses sensor data to make lighting decisions; in Manual Mode, it follows the user command directly.
• Step 4: The system updates the MySQL database and reflects the latest state (ON/OFF, Mode) on the dashboard in real time.

Design Features and Technologies Used

​

• The IoT web application is designed with usability, responsiveness, and real-time control in mind. Key design features include:
• • Simple and interactive UI developed using HTML, CSS, and JavaScript integrated with Django templates.
• • Backend built using Django REST Framework to provide lightweight and secure API communication.
• • Data persistence handled by MySQL, ensuring reliability and fast response for reading and writing states.
• • Cross-platform accessibility allows users to control their home lighting system from any device connected to the same network.
• • RESTful architecture ensures scalability and ease of integration with cloud platforms for future expansion.

Storytelling – A Real-Life Use Case

​

• Imagine a user named Rahul sitting in his living room on a cloudy afternoon. The lighting becomes dim, and the LDR sensor detects a low light level.
• The Raspberry Pi’s Controller Service switches the light ON automatically. On the web application dashboard, Rahul notices that Auto Mode is active, and the Light Control button is greyed out, indicating system automation is managing the light.
• Later in the evening, Rahul decides to disable Auto Mode using the dashboard. Instantly, the Light Control button becomes active, allowing him to manually toggle the light whenever he wishes.
• This seamless switch between automatic intelligence and manual control exemplifies the flexibility and practicality of IoT application design.

System Synchronization and User Feedback

​

• The application is tightly synchronized with the IoT backend to ensure that changes in light state or mode are instantly reflected on the dashboard.
• Whenever the system changes the light status — either through automation or manual command — a REST API updates the database. The web app fetches the new state and refreshes the display accordingly.
• This continuous synchronization guarantees accurate real-time feedback, ensuring the user always sees the true status of their home automation system.
• Moreover, user activity logs and sensor data can be extended to provide analytics, such as energy usage and device efficiency over time.

Conclusion – Completing the IoT Design Cycle

​

• The Application Development stage completes the IoT Design Methodology by connecting the user directly with the system’s intelligence.
• Through this interface, the user gains both convenience and control, while the underlying automation ensures efficiency and smart operation.
• The Smart Home Automation system is a perfect example of human-centered IoT design — where technology adapts to human behavior seamlessly.
• This final stage not only delivers functionality but also provides the foundation for future enhancements like AI-driven lighting prediction and cloud connectivity.

Case Study on loT System for Weather Monitoring

• In this section we present a case study on design of an IoT system for weather monitoring using the IoT design methodology.
• The purpose of the weather monitoring system is to collect data on environmental conditions such as temperature, pressure, humidity and light in ‘an area using multiple end nodes.
• The end nodes send the data to the cloud where the data is aggregated and analyzed.

Case Study on loT System for Weather Monitoring

Fig. shows the process specification for the weather monitoring system.

• The process specification shows that the sensors are read after fixed intervals and the sensor measurements are stored.

​

Case Study on loT System for Weather Monitoring

• In this domain model the physical entity is the environment which is being monitored. There is a virtual entity for the environment.
• Devices include temperature sensor, pressure sensor, humidity sensor, light sensor and single-board mini computer.
• Resources are software components which can be either on-device or network-resources.
• Services include the controller service that monitors the temperature, pressure, humidity and light and sends the readings to the cloud.

Fig. shows the domain model for the weather monitoring system.

Case Study on loT System for Weather Monitoring

Fig. shows the information model for the weather monitoring system.

• In this example, there is one virtual entity for the environment being sensed.
• The virtual entity has attributes- temperature, pressure, humidity and light.

Case Study on loT System for Weather Monitoring

• Fig. shows an example of deriving the services from the process specification and information model for the weather monitoring system.

​

• Controller Service: Runs as a native service on the device. Gets the current temperature, pressure, humidity and light readings and sends to the cloud database.

Case Study on loT System for Weather Monitoring

Fig. shows the specification of the controller service for the weather monitoring system.

• The controller service runs as a native service on the device and monitors temperature, pressure, humidity and light once every 15 seconds.
• The controller service calls the REST service to store these measurements in the cloud.

Case Study on loT System for Weather Monitoring

• Figure shows the deployment design for the system.
• The system consists of multiple nodes placed in different locations for monitoring temperature, humidity and pressure in an area.
• The end nodes are equipped with various sensors (such as temperature, pressure, humidity and light).

​

Case Study on loT System for Weather Monitoring

• The end nodes send the data to the cloud, and the data is stored in a cloud database.
• The analysis of data is done in the cloud to aggregate the data and make predictions.
• A cloud-based application is used for visualizing the data. The centralized controller can send control commands to the end nodes, for example, to configure the monitoring interval on the end nodes

Case Study on loT System for Weather Monitoring

Fig. shows an example of mapping deployment level to functional groups for the weather monitoring system.

​

Case Study on loT System for Weather Monitoring

Fig shows an example of mapping functional groups to operational view specifications for the weather monitoring system

Case Study on loT System for Weather Monitoring

Figure shows a schematic diagram of the weather monitoring system.

• The devices and components used in this example are Raspberry Pi mini computer, temperature sensor, humidity sensor, pressure sensor and LDR sensor.

7.1 Understanding IoT Devices

An Internet of Things (IoT) device refers to any physical object equipped with a unique identifier that can send or receive data over a network. These devices connect to the internet and exchange information either about themselves or their surroundings using embedded sensors. Through this connectivity, IoT devices enable seamless communication with servers, storage systems, and other devices. The primary purpose of IoT devices is to facilitate intelligent monitoring, remote control, and automation of various real-world systems.

How IoT Devices Work

• IoT devices gather data from their environment using sensors, process or package this data, and transmit it to cloud servers or interconnected systems through wired or wireless networks. These devices allow real-time tracking, analysis, and decision-making. They can also receive commands from remote users or automated platforms, enabling physical actions such as switching appliances, adjusting machine settings, or triggering alerts.

Examples of IoT Devices

• Smart home automation devices enable remote monitoring and control of appliances such as lighting and heating systems. Industrial IoT systems collect operational data and send it to servers for predictive maintenance. Connected vehicles share location and performance data with cloud services to improve navigation and safety. Wearable health devices measure parameters like steps or heart rate and transmit the data to cloud-based monitoring platforms.

7.1.1 Basic Building Blocks of an IoT Device

An IoT device consists of several essential modules based on its functionality. The sensing module gathers data from onboard or attached sensors such as temperature, humidity, or light intensity. The actuation module performs actions on physical devices, for example switching appliances on or off. The communication module enables the transfer of collected data to servers or cloud storage and receives commands from remote applications. Finally, the analysis and processing module interprets the sensed data and enables intelligent decision-making.

Single-Board Computer (SBC) Based IoT Device

A commonly used IoT device is a single-board computer such as the Raspberry Pi. It is widely accessible, inexpensive, and supported by extensive online resources. Before examining its architecture, it is important to understand the general building blocks of an SBC-based IoT device. These include the CPU, GPU, RAM, storage, and various interfaces such as UART, SPI, I2C, CAN, SD, MMC, and audio/video modules.

Figure 7.1: Block Diagram of an IoT Device

Overview of the IoT Device Block Diagram

• Figure 7.1 represents the architecture of a single-board computer (SBC)-based IoT device. It consists of multiple functional modules connected through a common interconnect. These modules handle sensing, processing, communication, storage, and multimedia operations. The diagram helps understand how different internal components work together to support IoT functionality.

Core Processing and Multimedia Blocks

• The Processor (CPU) is responsible for executing instructions, running the operating system, and handling data from sensors. The Graphics Processing Unit (GPU) manages visual output and multimedia rendering. Audio/Video interfaces such as HDMI, 3.5mm audio, and RCA video enable the device to connect to external displays and audio systems. The Connectivity module includes USB Host and Ethernet ports for wired communication and external device access.

Interfaces, Storage, and Memory Systems

• Interfaces such as UART, SPI, I2C, and CAN allow the IoT device to communicate with various sensors and actuators. Storage interfaces (SD, MMC, SDIO) support operating system storage and data logging. Memory interfaces connect the CPU to RAM (DDR1/DDR2/DDR3) and flash memory (NAND/NOR). All these functional blocks communicate via the system interconnect, forming the complete IoT architecture.

Exemplary Device: Raspberry Pi

• Raspberry Pi is a low-cost mini‑computer roughly the size of a credit card. It runs various flavors of Linux and can perform almost all tasks that a regular desktop computer can handle. In addition to computing capability, the Raspberry Pi supports interfacing with sensors and actuators through its general‑purpose input/output (GPIO) pins. Because it uses a Linux operating system, Python is supported natively, making it an ideal platform for IoT, automation, and educational projects.

7.3 About the Raspberry Pi Board

• The Raspberry Pi board contains several components and peripherals essential for computing and interfacing. Figure 7.2 illustrates these parts, which include processor, memory, communication ports, display interfaces, audio/video outputs, and general-purpose input/output features. This makes Raspberry Pi a versatile platform for IoT, education, robotics, and embedded system applications.

Processor, USB, Ethernet, and Video/Audio Interfaces

• The Raspberry Pi is powered by an ARM processor with onboard RAM. It includes two USB 2.0 ports capable of providing up to 100mA each. The Ethernet port is a standard RJ45 connector for wired networking. For display, Raspberry Pi provides HDMI output supporting digital audio and video, and a composite RCA output for analog video. The 3.5mm audio jack supports audio output for headphones or small speakers.

GPIO, Display, Camera, LEDs, Storage, and Power

• The board includes GPIO pins that allow interfacing sensors and actuators, making it suitable for IoT and hardware projects. The Display Serial Interface (DSI) connects official touchscreens, while the Camera Serial Interface (CSI) supports camera modules. Status LEDs indicate power, activity, and Ethernet status. Storage is provided through an SD card slot used for installing the operating system. Power is supplied through a micro-USB connector, ensuring stable operation of the board.

END