Green Awareness via IoT Infrastructure, Educational Labs and Games in Schools: The GAIA Case

Georgios Mylonas, Dimitrios Amaxilatis,
Irene Mavrommati and Joerg Hofstaetter
November 14, 2017

 

Educational buildings constitute 17% of the non-residential building stock in the EU [1], while recent work shows that a focus on energy use in schools can potentially yield an array of rewards, in concert with educational excellence and a healthy learning environment [2]. Having these in mind, GAIA 1, a Horizon2020 EC-funded project, is developing an IoT platform that combines sensing, web-based and gamification elements, in order to address the educational community. Its primary aim is to increase awareness about energy consumption and sustainability, based on real sensor data produced by the school buildings where students and teachers live and work, while also lead towards behavior change in terms of energy efficiency.

We believe that a participatory, ethical and sustainable engagement of students is a meaningful way to enable greater understanding of these concepts and lead to future well-informed, responsible and active citizens. In this sense, an approach based on open-source, replicable and widely available technology, providing a “foundation” that lets educators to adapt to the needs of each class, opens up many possibilities. To change the behavior and achieve sustainable results, GAIA utilizes a loop approach focused around 3 pillars: raise awareness, support action, and foster engagement. An overview of GAIA’s goals can be seen in Figure 1.

Figure 1: One way to achieve GAIA goals, outlined in this image, is by providing students with game challenges, which use real sensor data from their school.

Figure 1: One way to achieve GAIA goals, outlined in this image, is by providing students with game challenges, which use real sensor data from their school.

IoT infrastructure in GAIA: classroom nodes and educational lab kits

Currently, 18 educational building sites participate in GAIA, located in Sweden, Italy and Greece, aiming to cut down on their energy consumption. The total number of students in these sites is around 5500. An IoT infrastructure with 855 sensing points has been installed in these buildings to monitor energy consumption, as well as indoor and outdoor environmental parameters (temperature, light, humidity, movement, noise levels). Real-time feedback, stemming from the actual IoT sensors data, is provided via a number of user interfaces, community support tools, and a game.

The GAIA application set complements an educational approach that encourages customization to the specific requirements of each school. It is also accompanied by an educational lab kit and respective content, which will allow students to experiment with IoT nodes similar to the ones installed as school infrastructure. The lab kit is based on popular DIY electronics components, such as Raspberry Pi and conductive ink, and will be utilized by the students to implement “basic” IoT solutions to monitor their own environment (see Figure 2).

Figure 2:IoT nodes used in GAIA.

Figure 2: IoT nodes used in GAIA.

GAIA challenge and trials at schools

Figure 3: The GAIA Challenge

The GAIA Challenge2 is an online serious game for students, designed to raise energy awareness within their own facility. In addition, real-time data from sensors in the buildings and participatory sensing are a part of the challenge; the aim is  to visualize the real-life impact of the participants’ behavior and build collaborative (within a facility) and competitive (between facilities) gamification elements upon the real-life impact. The game challenge utilizes gamification mechanics to:

  • motivate participants to engage in energy saving topics;
  • work on online “quests”;
  • participate in real-life activities;
  • experience their impact on the facilities’ energy consumption over the course of the challenge;
  • compete and compare against other classes and schools in other countries;
  • share their experience within their peer group.

The online challenge is modular enough in order to support the diverse communities (from elementary schools to secondary schools and universities) and diverse knowledge items (energy efficiency for different energy sources, control of the room climate, resource sharing, etc.). Furthermore, it is localized in a number of languages, and includes diverse activities completed either on individual basis, or a class/group basis, either digital (e.g., filling in multiple-choice questions), or physical (e.g., monitoring the power consumption meters). To meet these requirements, local teachers are involved in Class Activities to work together with their students on hands-on observation and optimization tasks in classrooms.
For the validation of the GAIA services and applications, a set of trials will commence in October 2017 across Europe (Greece, Italy and Sweden), representing different climate zones, building age categories and socio-economic criteria. The GAIA Challenge has already been tested by 615 students of primary and secondary education, in May 2017, at the end of the school year. The game was primarily played by groups of students within the course of an educational activity.

Challenges and threats

A number of unique features and challenges exist in GAIA’s technical domain. Educational organizations (e.g., ministries) manage a large number of buildings. Additionally, in many cases existing school buildings are often quite old, have central heating or cooling, having limited possibilities in control, etc. Moreover, such entities wish to avoid vendor lock-in, while a single solution in terms of infrastructure is impossible, since each educational building has different characteristics. Furthermore, since we are talking about the educational community, data should be utilized in an educational setting. GAIA attempts to tackle these challenges by using standards-based solutions that follow current engineering practices, while being open-source-based as much as possible.
A serious challenge is also the overall educational strategy of the project. While previous similar projects have taken an approach based on providing ready-made solutions, with a concrete set of educational material to be used in classes, this is not an ideal solution. In many cases, schools have unique schedules and characteristics that cannot be handled with a one-size-fits-all approach, especially when discussing activities that are outside of the standard curriculum dictated e.g., by the national ministries of education. GAIA will attempt to provide the tools on top of which educators can adapt their own lectures and schedule.

With respect to the design of the application toolset, GAIA’s end-user communities include people of diverse age, which implies that different communication channels have to be supported. In addition, customization to the automation level of each school is mandatory. Moreover, the localization of the application is crucial for the penetration of the applications and this does not refer only to language but also to the roles and availability of staff to implement energy efficiency campaigns. E.g., while in Sweden the role of building manager is held by dedicated personnel, in public schools in Greece and in Italy, this role is undertaken by school principals. Additionally, there are fears over privacy issues related to the IoT. Such issues are handled by being completely transparent in terms of what is being monitored inside schools, while also using anonymization in the produced datasets.

References

  1. Europe’s buildings under the microscope: A country-by-country review of the energy performance of buildings. Technical report, Buildings Performance Institute Europe (BPIE), 2011. ISBN: 9789491143014
  2. K. Crosby and A. B. Metzger. Powering down: A toolkit for behavior-based energy conservation in k-12 schools. Technical report, U.S. Green Building Council (USGBC), 2012.

1GAIA project website, http://gaia-project.eu
2GAIA Challenge website, http://gaia-challenge.com/

 


 

Georgios MylonasGeorgios Mylonas is a senior researcher at Computer Technology Institute and Press “Diophantus”, Patras, Greece. He received his Ph.D., MSc and diploma degree from the Dpt. of Comp. Engineering and Informatics at the University of Patras. His research interests lie in the areas of IoT, wireless sensor networks, distributed systems and pervasive games. He has been involved in the AEOLUS, WISEBED, Smartsantander, AUDIS and OrganiCity projects, focusing on algorithmic and software issues of wireless sensor networks. He is currently the coordinator of the Green Awareness in Action (GAIA) H2020 project.

 

Dimitrios AmaxilatisDimitrios Amaxilatis received the B.S. in Computer Engineering and M.S. in Computer Science from the University of Patras, in 2011 and 2013 and is currently a Ph.D. student in the same University. From 2010, he has been a researcher with the Computer Technology Institute in Patras, Greece. He was also member of the founding teams of two technological startups in the fields of microprocessor programming (codebender.cc) and home automation (Sensorflare), as well as the Patras hackerspace (P-Space). His research interests include distributed algorithms, wireless sensor networks, home and building automation, smart city and participatory sensing applications.

 

Irene MavrommatiIrene Mavrommati is Assistant Professor at Hellenic Open University, initially trained as interaction/UX/UI designer. She has participated, acquired and led EU Future Emerging Technology (FET) research projects and served as steering group of the Disappearing Computer network and Ubicomp related conferences. She is active in interactive art installations and technology exhibitions, and has authored book chapters and research articles focusing in interaction within ambient computing environments.

 

Jorg HofstatterJörg Hofstätter is founder and managing partner of ovos, a digital design agency in Vienna. At Ovos, Jörg is responsible for business development for Online projects and games. He is a trained Architect at the academy of applied arts Vienna at Studio Hadid and has dealt with online technologies and Games for over 15 years. He is frequently invited to international conferences to speak about Serious Games and virtual/augmented space.

 

 

RAMI 4.0 for Pizza Lovers

Vivart Kapoor
November 14, 2017

 

The reference architectural model for industry or simply RAMI 4.0 is a three-dimensional representation of crucial aspects of the industry 4.0. The aim of the model is smaller and simple clustering of complex interrelated industry processes . But what if the model itself is complex to understand? Let’s try to understand first the different layers of the model with the help of “Basic pizza baking process” and activities associated with it.

Figure 1: Reference Architectural Model Industry 4.0 (RAMI), Credit: ZVEI.org

Figure 1: Reference Architectural Model Industry 4.0 (RAMI), Credit: ZVEI.org

In Figure 1, the processes mentioned on the left (Asset-Business) describes technical as well as the business perspective of your product (in our case: Pizza). There, for instance, asset describes physical components: flour, tomato paste, spices, oven, the recipe and even the baker who bakes it, is an asset.

  • The integration layer deals with easy to process information content and can be considered as a bridge between real and IT world. In our case, it could be a sensor on the top of pizza which tell the baker about its current state (semi baked, baked) as well as other information like temperature, crisp and so on.
  • The communication part is responsible for the standardized communication between integration and information layer. Now image the sensor we mentioned above speaks Italian but the baker can only understand English which in our case is the “standard” worldwide. Here is where communication layers come into play.
  • The information layer as the name suggests holding the necessary data in a structured and integrated form. For us, it is a structured log (date, time, type) of data which we got from our pizza sensor for the last 1000 pizza ordered.
  • The functional layer is responsible for the “action to be taken” based on the information received as well as it is a channel for horizontal integration of various functions. How to avoid over-baking of a pizza? How to reduce the overall baking time? How to coordinate the order-intake, backing and delivery? These questions are addressed.
  • The business layer describes the business model mapping, business processes which can be adjusted based on inputs from the functional layer and legal and framework condition. In our case, it is the description of raw material (floor, tomatoes, cheese, etc.) procurement, pizza baking process, advertisement of the pizzeria, pricing models (buy 2 get 1 free) etc.

Well, it was easy to find an analogy describing various layers of RAMI model. But if our pizza shop owner wants to modernize his pizza shop and want to turn into a pizza startup? The aim of this startup is to increase the value proposition by expanding the product portfolio. Yes, I am talking about different kinds or “designer” pizzas. Let’s term it as “pizza prototyping”. This is where we start talking about the “Life cycle value stream” in the RAMI model. So how the above-defined layers are associated with life cycle value stream? For this, let us assume that our start-up wants to design a chocolate pizza with a special crispy/cookie base and chocolate spread and cacao topping on it. Now before, I start explaining the different design and development process of our product, let me give you a quick background of product life cycle and its meaning in RAMI model.

Every product has a life cycle which begins with idea generation, design concept, prototype testing and continues with manufacturing, delivery, service and maintenance and end ups with product phase-out or disposal. RAMI 4.0 model not only addresses the product life cycle of the product as a whole but also of its components. In our case, the chocolate pizza is the complete product and cookie base, chocolate spread and toppings, crème etc. are the components. Even our new pizza has a complete product life cycle: the owner has a fresh idea for a new pizza and then he comes up with a design (flavor and ingredients) of it and further it goes into production (baking or mass-baking) and it ends up with phase out (taking chocolate pizza off the market).

Talking about the life cycle of the components, even the key ingredient of our new pizza i.e. cookie base, chocolate spread etc. had gone through almost all these stages.

So what are Types and Instances in the RAMI model? As long as our pizza is in design development phase, it is a Type. Once it goes into the production, it becomes an Instance. If our pizza baker plans to redesign the pizza with some enhancement (two flavored or square shaped, chocolate pizza ver. 2.0) then the instance turns back to type. Important to know is that every instance has a unique id. In our case, the pizza startup owner decides to carve a unique ID on each pizza as well as each delivery box for easy tracking of orders.

That’s all about the product life cycle value stream of the RAMI model. However, the question remains, how is it connected to the process layers? This can be explained by the means of the figure below.

 Figure 2: Process layer vs Product life cycle.

Figure 2: Process layer vs Product life cycle.

In figure 2, the terms development and maintenance usage under type refers to development and revision related information and content respectively. The terms production and maintenance usage under instances refers production related and service/product enhancement related information respectively.

It is not always easy to categorize the information related to the product life cycle value stream under the process layers and there is always some room for mistake. In my example, I tried to categorize the information related to product life cycle of our pizza, based on various process layers. Here the “Information” layer under “Type” (at the design stage) contains data, which is relevant to the product design and prototype, for example best temperature, the time needed to bake it and so on. However, the “Information” layer under “Instance” has to do more with the production stage (mass-baking) i.e. batch detail (amount of pizzas in a shift) and data on quality (number of bad out of good pizza).

Similarly, the maintenance usage under “Type” hints towards the design revision relevant data and the maintenance usage under “Instance” deals with service related data. In our example, the functional data under maintenance usage of “Type” (new rule for better bake) talks about new or better baking techniques created after a specific number of test bakes but the functional data under maintenance usage of “Instance” is a complaints log (for late delivery, bad taste etc.)

Now what if the pizza shop owner decides to scale-up his startup to a pizza production? A leap from a start-up to a production facility is not easy and it demands state of art planning and documentation. This is where the “Hierarchy levels”, the third axis of RAMI 4.0 model, comes into picture. Nowadays since, all the production processes are interlinked and being monitored, controlled and documented automatically, we will now have a look how it functions with our pizza business and how we can align the information with the help of RAMI 4.0 structure. But before we do that, let us try to understand the third axis “Hierarchy levels” of the RAMI 4.0 model.

The hierarchy levels are based on the Purdue Enterprise Reference Architecture (PERA) or simply Purdue model which describes the different levels of electronic or software application and controls in manufacturing. It comprises of:

  • Field device: Sensors, actuators, hardware etc. (Input-output). For example, temperature and humidity sensor for pizza bread production band.
  • Control device: Devices controlling the equipment that are attached to (PLC, SPS). For example, device maintaining optimum temperature of oven based on inputs of field device layer and monitoring the deviation.
  • Station: Supervisory control, monitoring and control of processes as well as event storage layer (SCADA). For example, coordination of various pizza baking processes (bread baking, tomatoes crushing etc.) and monitoring all events (No. of bake instances, instances of overheating) for a short period of time. 
  • Work Center: Data storage, analysis and documentation layer (MES). For example, work center showing daily/weekly/monthly review and baking performance in terms of quality (bad bake) and production efficiency (incline/decline).
  • Enterprise: Overall management of core business processes (ERP). For example, overall record of production vs procurement, order intake vs production, expenses (salaries, electricity bill, machine maintenance etc.)

The RAMI 4.0 model includes two more layers i.e. the product (for instance the pizza itself) at the bottom and connected world (an ecosystem consisting customers, suppliers, service providers etc.) at the top.

It is obvious that we need all the above-mentioned layers in order to effectively synchronize as well as optimize the complete pizza production and associated processes. The connected processes or layers can minimize the overall production work load for instance: production data derived from work center layer, coupled with ERP can help automated procurement of raw material (wheat flour, tomatoes) at a price which suits the production capacity vs. demand (peak vs. low season).

So how the two axes discussed earlier do are associated with “hierarchy level”? The answer is simple: You just arrange the information depicted in the table in above based on its relevance in relation to the discussed levels. Here, for instance, you take an element of process layer (for example “asset”) and mention all life cycle and value streams (“type” and “instances”), relevant information based on different “hierarchy levels” keeping the definition of that particular process layer in mind.

Figure 3: Example illustrating the association and interpretation of 3 axes of RAMI 4.0 model.

Figure 3: Example illustrating the association and interpretation of 3 axes of RAMI 4.0 model.

In figure 3, we listed all possible “assets” (hardware, software, documentation, processes, humans etc.) concerning the different hierarchy levels, for complete life cycle and value stream. For this particular example, we assume the transition from pizza start-up (manual processes) to advance pizza production (automated processes).

The same applies for other process layers of the RAMI model. Here again, one should not mix the definition of different process layers and should properly differentiate the “type” and “instance” of the product life cycle and value stream. The “hierarchy level” under “information layer” might contain values like temperature values, signals etc. under field device, set values for best pizza bake under control device, number of cycles/pizza baked and fails events under station, production cycle data (hours, events, etc.) under work center and so on.

 [1] https://www.zvei.org/


 

Vivart KapoorVivart Kapoor is a project manager at KSB AG in Germany where he is involved in various IoT/digital transformation projects. As a hobby blogger, he contributes regularly his expertise and knowledge in the field of the internet of things to several IoT expert panel or blogging sites. Vivart obtained his Bachelors in Biomedical Engineering from Manipal Institute of Technology in India and Masters in Technical Management from University of applied sciences in Emden, Germany.

 

 

The Importance of a Context Sharing Architecture for Enabling the Internet of Things

Everton de Matos and Fabiano Hessel
November 14, 2017

 

By embedding mobile networking and information processing capability into a wide array of everyday items enabling new forms of communication between people and things, and between things (devices) themselves, the Internet of Things has been adding new dimensions to the world of information and communication technology. An important consideration about IoT is how to capture the context in which the devices operate. Context can store relevant information about the devices and their events. However, current context systems provide context information only locally in specific domains and not shared with other entities, which is mandatory to have a horizontal approach.

IoT devices generate many data, which will only be useful if we can analyze, interpret and understand it in a proper way, turning it into context information. However, with the integration of different IoT environments (e.g., healthcare, urban traffic, public city services) to provide relevant solutions, only providing context is no longer enough. In this sense, sharing context information between different environments and systems has become mandatory [1].

Context sharing is largely neglected in the context-aware domain. Indeed, most of the systems or architectures for context management are designed to facilitate applications in isolated factions, and inter-systems communication is not considered to be a critical requirement. However, in the IoT, there are no central point of control, which means different systems developed by different parties can be employed in the environment to connect to things (e.g., sensors, actuators), and thus collect, model, and also reason about the environment context.

There is a need to define a system that goes beyond vertical solutions by integrating all required technologies and components into a common, open, and multi-application platform [2]. There is also a need to develop a set of common building blocks and services that can be used to construct people-oriented applications in an open, dynamic, and more effective way into smart environments, including but not restricted to smart cities, businesses, education and e-health. Context Sharing Architecture becomes mandatory to make context sharing considering different aspects of IoT such as heterogeneity, interoperability, and real-time processing.

Context-awareness and sharing requirements

Figure 1 presents a context-awareness taxonomy for IoT environments. According to the taxonomy, we can split the context-awareness in four main steps, named the context lifecycle. The four phases of context life-cycle are essential to produce context information. Each phase of the life-cycle has its own challenges. The challenges of the acquisition step are related to the context-aware system capability to support the registration of new data sources (i.e., data providers, sensors, and devices), and its technical issues, as well as the network communication used to acquire the data sources information.

Figure 1: Context-awareness taxonomy for IoT.

Figure 1: Context-awareness taxonomy for IoT.

The modelling and reasoning phases has the same challenges because these phases strictly depend on each other. The pre-processing is related to handle imperfect and ambiguous data in the modeling to facilitate the reasoning process. Security and privacy are essential for these phases to protect the context information in many ways (e.g., authentication, access control, and data protection). The data fusion is related to the functions of data aggregation, fusion, mathematical and statistical. These functions may occur in the reasoning phase in order to produce context information.

A standardization for the data formats is a challenge in the distribution phase. This standardization can be reached with unit conversion, data customization, or alternative data structures. Accessibility is another distribution phase challenge. A context-aware system must provide accessibility through APIs, documentation, and multiple options or alternatives of system use.

The use of context sharing enables computational entities such as agents and services in pervasive computing environments to have a common set of concepts about context while interacting with one another. By reusing well-defined context of different domains, we can compose large-scale context information without starting from scratch.

Next items present a description of the requirements that a possible Context Sharing Architecture must address to meet all the context-awareness challenges [3] [4].

  • Heterogeneity: Different from the most context systems that comprise only an application-specific system (i.e., a vertical domain), components of shared systems might be highly heterogeneous along several dimensions and applications, such as: how the context is produced, consumed, and understood. Currently, there is no standard context notation format. Although there is a wide range of applicable context information, it is impossible to make a one size fits all notation format;
  • Systems Management: In an IoT environment, large number of various types of devices are able to connect to the network. The Context Sharing Architecture must allow that those devices can register in the architecture to enable the interoperability with shared systems;
  • Processing of Context Information: If large numbers of various types of devices become ubiquitous and can be connected by IP networks, it will not be realistic for those requesting context information to specify context from a certain device. In this sense, it requires the architecture to have the smart capacity to obtain, produce, and share the context information of a high-level request;
  • Scalability and Real-time: Massive quantities of all sorts of context information need to be processed at high speed and in an efficient way;
  • Security and Privacy: Authorization and access control are indispensable for management of context information, once it often includes extremely private information such as user location and preferences. Concerning privacy protection, it is necessary to specify to what extent the information may be disclosed and must be provided with a means to trace and destroy the information if necessary.

Considerations about the existing gap

A context sharing architecture that provides relevant approaches regarding heterogeneity, system management, processing of context information, scalability and real-time, and security and privacy should be defined. There are some approaches that already address these challenges separately. Therefore, adapting them to enable the context sharing in IoT environments would be beneficial for the sharing architecture definition.

The importance of having a Context Sharing Architecture is strongly related to the need of people sharing information between different places. Although the context sharing concept is used in the pervasive computing area by some systems, the sharing mostly occurs locally with a small group of similar entities, not taking into account the possibility of a heterogeneous environment, what is very common in IoT. There is a need of providing a Context Sharing Architecture able to share context information between heterogeneous entities considering the context management in a secure and interoperable way.

Regarding the use of existing technologies to develop such architecture, OWL of the Semantic Web standards may be applied to the common context description scheme of systems that made context sharing process. According to the World Wide Web Consortium (W3C), “the Semantic Web provides a common system that allows data to be shared and reused across application, enterprise, and community boundaries”. The ultimate vision of the Semantic Web is to make automated semantic agents access the Web on their own and carry out tasks only by referring to the semantics encoded into the Web page on behalf of users.

Even that ontology works for the standardization by mitigating the heterogeneity challenge, this is a complex issue and other technologies need to be employed. Web services can be used to hide the context systems patterns in order to standardize the communication channel used for the context information transport.

The security is one of the main challenges towards the definition of such architecture. There is a need to protect contextualized information exchanged between entities. In this sense, the use of DTLS protocol is a viable choice to protect communications channels, since it is not a protocol designed for resource-constrained environments. Authentication, authorization, confidentiality, and integrity must be used to protect the proposed architecture.

Although the definition of a context sharing architecture is noteworthy, it is mandatory to be careful with the way in which it is developed. There are two relevant challenges to overcome. The first challenge is to understand the way in which context will be standardized in order to be shared. The use and optimization of web services and Semantic Web can be a first step towards the mitigation of this issue. The second challenge is related to scalability and real-time sharing. There is a need to optimize mechanisms in order to minimize the data/context traffic between entities. The use of Edge Computing concept, which is related with data processing in the edges, may be a way of reducing the extra information exchanged.

References

  1. C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Context aware computing for the internet of things: A survey,” Communications Surveys Tutorials, IEEE, vol. 16, no. 1, pp. 414–454, 2014.
  2. F. Boavida, A. Kliem, T. Renner, J. Riekki, C. Jouvray, M. Jacovi, S. Ivanov, F. Guadagni, P. Gil, and A. Trivino,˜ People-Centric Internet of Things—Challenges, Approach, and Enabling Technologies. Cham: Springer International Publishing, 2016, ch. 44, pp. 463–474.
  3. K. Nihei, “Context sharing platform,” NEC journal of advanced technology, vol. 1, no. 3, pp. 200–204, 2004.
  4. Kansal, S. Nath, J. Liu, and F. Zhao, “Senseweb: An infrastructure for shared sensing,” IEEE MultiMedia, vol. 14, no. 4, pp. 8–13, Oct 2007.

 


 

Everton de MatosEverton de Matos has been working with Internet of Things technologies since 2014. He is a Ph.D. candidate in the area of context-awareness for Internet of Things, at the Computer Science School at the Pontifical Catholic University of Rio Grande do Sul (PUCRS), acting at Embedded System Group (GSE). He has experience in computer science and his research interests are IoT, Middleware for IoT, and context-awareness in IoT environments. Contact him at everton.matos.001@acad.pucrs.br.

 

Fabiano HesselFabiano Hessel is Associate Professor of Computer Science at PUCRS (Brazil), Research Productivity Scholarship from CNPq and act as Advisor in the Office of the PUCRS Vice-President for Innovation, Research and Development. He received his Ph.D. in Computer Science from Joseph-Fourier University, France (2000). He is the head of Embedded System Group (GSE) and the Coordinator of the Smart City Research and Innovation Center at PUCRS. Professor Hessel is member of the IEEE and of the Brazilian Computer Society (SBC). His research interests are embedded real-time systems, RTOS and MPSoC systems applied to Internet of Things and Sustainable+SmartCities. Contact him at fabiano.hessel@pucrs.br.

 

 

ΙΕΕΕ-Powered IoT Implementation and User-Adoption for Win-Win Value Extraction

Harris Moysiadis
November 14, 2017

 

The Internet of Things (IoT) has now been around for at least a decade. A wide community of technologists and futurists have schematically envisioned a world where direct machine to machine communications will disrupt many of the human to human routine interactions. However, in order to get there IoT practitioners have to incrementally introduce IoT in the socioeconomic conditions they currently face. This article focuses on ideas for gradually overcoming business issues for SMEs in order to move from the technology-creation side to the one of real economy’s using a paradigm of a Greek case.

As an introductory note, any new or late comer in the field has to understand that what makes the IoT a real game-changer is its potentiality in interoperable, vendor-agnostic, cross-domain and cross-border manipulation of data acquired by those “things”. That said the use of widely adopted standards should be preferred when compared to rapidly developed proprietary solutions. IEEE for instance is a highly skilled community with many IoT standards, working groups and useful material to follow and embed in any company’s commercial solution portfolio. Moreover, in-depth understanding of areas like Big Data (BD) and Cloud Computing (CC) are a pre-requisite in order to unveil the full potential of IoT especially in cross-domain areas and business models. Thirdly, it is proposed for an SME to focus on a market-niche and partner with relevant actors for launching the IoT product/ service. Such a commercial value proposition sources its activities from extended multi-organisational boundaries thus requiring to build a trusted partnership approach.

Building cross-cutting IoT business models-Reflections from an SME

Management-wise the IoT era comes along with a mind-set shift from shareholders to stakeholders. The resources needed for successful and sustainable IoT implementations often reside outside the company due to IoT technology’s distinctiveness. As a result, resources needed to build common ground among all inter-connected players like original equipment manufacturers (OEMs), research and technology development (RTD) organisations, technology offerors (CC, BD, 3rd party app developers) and relevant business and end-user alliances. Last, a well-described national IoT Action Plan would outstandingly support the under development bridging ties for such ecosystem creation liaised with similar global initiatives.

Unfortunately, organisational re-engineering is not the main barrier for delivering at last a long-lasting IoT deployment. In a constantly changing market landscape with conflicting interests it is necessary to start building the partnership approach with the fellows that are able to understand the added value the proposed niche intervention has on their products and services, market-share and viability. Again not an easy task since it is common that the IoT proposer may confront with this partner dominant position in the market value-chain and well-established business relationships that precede any technological skill or offer. In that case, end-users (market) changing behaviours’ justification is a critical to have claim coupled with a similar, engaged, partnering expertise (marketing).

Furthermore, SME-related day-to-day challenges involve continuous technology development and alignment with the adopted and emerging standards. And when we talk about IoT there is a wilderness of them out there. This means that a lot of in-house spending occurs for immature technologies and setting up a system-wise learning curve. Fast but well-analysed take up and agile engineering development is a must combined with the vital need to move out of lab to real-life prototypes, demos and pilots. Doing so, the rest of the community may be timely motivated, co-form a business case that enable the SME to follow a lean approach focusing only on activities that add value to the marketable IoT solution.

Constrained locality embrace globalism: building the 1st Greek IoT Campus

Among others, IoT facilitates the creation of the Digital Single Market (DSM) in EU. However, inequalities among west-north and central-east Member States (MS) are expected to grow hence their share in EU Data market economy will relatively follow. Currently initiated project-based synergies may not be enough to cover the existing gap neither in IoT uptake nor supply. Alternatively, focus on national priorities and regional strengths aligned to MSs’ “competitive-diamonds” integrating various heterogeneous infrastructures may be an appropriate strategy for an EU level-playing field for IoT. Such a case is described in the paragraphs below just before its scale to relevant key local domains.

Future Intelligence (FINT1) is a Greek SME founded in 2009 in Athens. Since 2014, the company offers a generic, flexible and low-cost IoT platform for connecting any object (sensor/ actuator) on the internet using IEEE and other well-adopted industry standards. Having been around as long as the Greek crisis had anyone can add more layers of barriers (capital, trust, uncertainty) to the previous discussed reflections. However, FINT’s RnD intensive orientation enabled it to overcome the valley of death and continue optimising its innovative solutions for Smart Cities and Smart Agriculture. The company located its headquarters in Attica’s Technology and Scientific Park within Greece’s biggest Scientific and Research Center, NCSR Demokritos (NCSR DEMO) campus.

Luckily, apart from being the property owner NCSR DEMO surrounds a plethora of RTD Institutes (e.g. Telecom, Environmental, Chemical, Radio, Nanotechnology and more) and spin-offs and essentially the culture of innovation. NCSR DEMO was contacted for joining forces and extend the existing FINT’s partnership portfolio as described above.

The two organisations decided to transform the campus to the first IoT park in Greece aiming to attract additional interest (business cases, products, services) from proximate organisations and authorities. FINT’s plan started from replacing the campus lighting infrastructure with remotely-controlled and contextually adaptive LEDs to reduce energy and costs. Via a single-sign in the administration platform, NCSR DEMO’ operators can also interact with microclimate sensors and irrigation actuators profiles set-up to optimise the campus’ landscape watering. The win-win cooperation just kicked off and the target is to rationalise the park’s input resources where possible. Consequently, partners will extend the pilot’s impact to additional campus’ operations and needs’ fulfilment that will be then validated and launched as business propositions for emerging markets (security monitoring, waste collection).

Summing up, rapid real-life IoT pilots are vital for pushing technology even further, partially removing some of the barriers identified above. Yet, the unveiling of positive side-effects for the local community and the ability to access, create, correlate and consume content and find additional ways to monetise it is also a critical success factor. Local solutions that address global needs offered through cross-domain business models for the 4th Industrial era pave the way for decentralised, sustainable and inclusive progress. Let us then orchestrate our IoT forces accordingly!

Figure 1. ΙΕΕΕ-powered IoT interventions in Demokritos campus: Left, smart LED posts. Middle, FINT’s cross-domain (Smart Cities/ Agriculture) IoT solutions for fast market deployment. Right: Basic FINoT AgriNode © Future Intelligence.

Figure 1. ΙΕΕΕ-powered IoT interventions in Demokritos campus: Left, smart LED posts. Middle, FINT’s cross-domain (Smart Cities/ Agriculture) IoT solutions for fast market deployment. Right: Basic FINoT AgriNode © Future Intelligence.

Further reading

  1. Advancing the Internet of Things in Europe, Staff Working Document. Available at: https://ec.europa.eu/digital-single-market/en/news/staff-working-document-advancing-internet-things-europe
  2. Mid-Term Review on the implementation of the Digital Single Market Strategy: A Connected Digital Single Market for All, Staff Working Document. Available at: http://ec.europa.eu/newsroom/document.cfm?doc_id=44542
  3. AIOTI Recommendations for future collaborative work in the context of the Internet of Things Focus Area in Horizon 2020. Available at: https://ec.europa.eu/digital-single-market/en/news/aioti-recommendations-future-collaborative-work-context-internet-things-focus-area-horizon-2020

[1] http://www.f-in.gr/


 

Harris MoysiadisHarris Moysiadis is the Business Development Manager of Future Intelligence, an IoT original equipment and solution provider (http://www.f-in.gr/). His research interests focus on the business implications of ICTs, mapping their intervention in Business Process cycle within Smart Cities, Smart Agriculture and more. His aim is to effectively combine ICTs' transformative power on Collaborative Social Capital forces and deliver smart and novel, win-win business models. Harris graduated from Athens University of Economics and Business (BSc in Business Administration) and holds an MSc in Information Systems: Business IT from Manchester Business School, UK. He is also FINT’s Project Manager for INCOVER project, http://incover-project.eu/, which supports part of FINT’s work in Smart Farming.