The Impacts of Low/No-Code Development on Digital Transformation and Software Development

Low/No-code development is a software development method that provides users with a platform for visually creating applications with little or no coding. Companies and organizations need software applications and information systems for various business purposes like management in the technology era. Low/No-code development gives non-IT professionals a convenient tool for rapidly building simple business applications they need without or with little coding. In this paper, we explored the benefits&limitations of Low/No-Code development and modern Low/No-Code development platforms in the industry. In addition, we analyzed how it can be improved and prospected the impacts of Low/No-Code development on society and related industries in the future. In conclusion, we find that Low/No-code development is a promising trend that can significantly impact future software development and digital transformation.

INTRODUCTION
With the development of information technology and digitalization trends, companies and organizations require robust tools to respond to dynamic & complex market environments and requirements (Sanchis et al., 2020) [1]. In his journal Software development trends 2021, McLean (2021) defines Low/No-Code development as a sort of visual software development that developers can use to drag & drop and connect components for building mobile or web applications [4]. Such a component-based approach empowers professional developers to deftly create applications without any code (McLean, 2021) [4]. In 2014, Richardson and Rymer (2014) first brought in the phrase "low code" to the public in their report titled "New Development Platforms Emerge For Customer-Facing Applications," published in Forrester Research, in which they claim that comparing to demanding hand-coding, enterprises and organizations prefer low-code substitutes for swift, continual, and test-and-learn development and delivery [2].
The result of an investigation conducted by Richardson and Rymer (2016) illustrated that low code development platforms could help enterprises and organizations expedite the development and delivery of applications by 5 to 10 times [3]. Gartner, a technology research and consulting company, forecasts that Low-Code Development will be used for 65% of application development projects by 2024 (Duffy, 2019) [5]. Therefore, it is crucial for the public to understand LNCD comprehensively when LNCD is rapidly adopted and embraced by enterprises and organizations.
Nevertheless, though Low/No-Code Development has many good for application development, some enterprises do not adopt it over conventional software development process due to the dearth of knowledge about Low/No-Code Development Platforms (LNCDP), fear of vendor lock-in (i.e., fear of being dependent on an LNCDP vendor), the scarcity of confidence that LNCDP can develop desired applications, worries about the security, scalability, and inflexibility issues (OutSystems, 2019) [7].
However, some of the concerns about LNCDP, such as inflexibility, scalability, and security, were defended or proved to be manageable by Warren from OutSystems (2018) [8]. Alsaadi et al. (2021) analyzed leading LNCDP developers such as OutSystems, Microsoft, Salesforce, Mendix, and Appian [11]. We will analyze the features and functionalities of these platforms and focus on the insight we get by looking at trends and patterns in the Low/No-Code industry.
In the last section of this paper, we prospect how Low/No-Code development will affect future software development and digital transformation by analyzing opposite opinions.
We conclude that even if Low/No-Code Development emerged only a few years ago, the rapid growth of its adoption in the industry indicates an optimistic prospect. Based on our analysis in each section, Low/No-Code Development will cause a turnaround in the software development industry and conduce digital transformation.

II. BENEFITS AND LIMITATIONS OF LOW/NO-CODE DEVELOPMENT
In today's society, it becomes more critical for enterprises and organizations to adapt to fast-changing both external and internal environments (OutSystems, 2019) [7]. As defined by Alsaadi et al. (2021), digital transformation usually refers to digitalizing paper-based documents and storing them in a digital form [11]. It transforms the business processes from time-consuming and labour-intensive manual processes to automated agile digital processes (Alsaadi et al., 2021) [11]. According to Outsystems (2019), digital transformation has been playing a significant role in business strategy for a few years [7]. Organizations leverage digital transformation to grasp new opportunities, to satisfy customers' complex and various needs, and to circumvent being defeated by competitors that become more adaptive and flexible (OutSystems, 2019) [7]. Outsystems (2019) investigated over 3,300 IT professionals from 6 different continents, and Figure 1 shows the results regarding business digital transformation progress. According to Outsystems' (2019) criteria, Level 1 Unaware is doing almost nothing for digital transformation; Level 2 Isolated is the preliminary stage of digital transformation, and Level 6 is the most robust stage [7]. We can conclude from the chart that the majority (95%) of the respondents' organizations were more or less making efforts for digital transformation.  Figure 2 shows that 23% of the respondents planned to develop and deliver over 50 software applications. Figure 3 shows that majority of the applications are required over three months. We conclude from these two graphs that during digital transformation, there will be numerous and continuous demands for new application development and delivery, which can be time-consuming. Therefore, organizations that plan to or are digital transforming need a tool to improve development & delivery efficiency. Low/No-code development is one of the rising approaches to boost delivery speed. Figure 4 illustrates the percentage of Low/No-code adoption in the IT strategy of respondent organizations, where we can see that over half of them will start or are utilizing Low/No-code development. The study of Richardson and Rymer (2016) indicates that Low/Nocode development can speed up the applications development & delivery by 5 to 10 times [3]. According to Duffy (2019), Gartner predicted that, by 2024, Low-Code Development would take on 65% of application development tasks [5]. For the Digital Transformation Maturity (DTM) we mentioned in Figure 1, the average DTM score of Low-Code practitioners was 16% higher than that of industry peers who did not use Low-Code (Outsystems, 2019) [7]. Moreover, 37% of businesses that practiced Low-Code development were satisfied with the software application delivery rate, while only 26% of businesses that did not practice Low-Code were content with their release rate (Outsystems, 2019) [7]. Therefore, it is important to learn more comprehensively about Low/No-code development before using it during digital transformation. In this section, we explore both benefits and limitations of Low/No-code development for developers and organizations to pounder if it is felicitous with their digital transformation strategy.   A. BENEFITS There are many goals that developers want to achieve using Low-code development. Outsystems (2019) collected top reasons for utilizing Low-code development, and the first three were Expedite digital innovation/transformation (66%), Improve responsiveness to the business (66%), Decrease dependency on the technical skill that is hard to hire (45%) [7]. Besides these general responses, we expand several main benefits that Low/No-code development can produce in this sub-section.
a. Swiftness By the nature of Low/No-code development, Low/No-code development platforms allow users to build new applications visually, which accelerate development by providing businesses with immediate prototyping new customer requirements and testing of the functionalities (Richardson & Rymer, 2016) [3]. Richardson and Rymer (2016) also argued that coding a new software application is still a demanding and time-consuming task, even though practicing Agile or Lean software development process [3]. Modifying a customized application with numerous lines of code is also complicated and inefficient (Richardson & Rymer, 2016) [3]. Most of the enterprises using Low-code platforms reported that Low-code development conduced to their release of applications and speeded it up by 5 to 10 times (Richardson & Rymer, 2016) [3]. As presented in Outsystems (2019) survey, Low-Code practitioners could release 68% of their web applications in 4 months, while non-Low-Code users could only deliver 57% of their web applications using the same amount of time [7]. For mobile apps, it presented a similar pattern where Low-Code practitioners could deliver 64% of the apps in 4 months, but those who did not use Low-Code could only deliver 49% of apps in 4 months (OutSystems, 2019) [7].
b. Citizen Development Citizen developers are non-professional developers authorized by the IT department to use approved tools for application development & delivery (OutSystems, 2019) [7]. Though citizen developers lack programming skills, they have abundant experience and knowledge in other fields; since programming skills are hardly needed when using Low-Code, citizen developers could use the knowledge and experience to develop applications that meet customers' needs better (Alsaadi et al., 2021) [11]. When the enterprises have a dearth of IT talents but with a myriad of demands of new web/mobile applications from various departments, citizen developers in each department could use Low/No-Code development platforms to build needed business applications for their departments (Richardson & Rymer, 2016) [3]. It not only satisfies departments' needs but also releases IT professionals from tedious low-level application development details. IT professionals could then focus on more complex and essential business application requirements. Outsystems (2019) assessed the administration of citizen developers and found that 37% of Low-Code practitioners could administrate and manage citizen development attentively, which was 9% higher than that of non-Low-Code users [7]. Therefore, Low/No-Code development improves citizen development on the developer and administrator sides.
c. Security During digital transformation, the limited number of IT talents makes it hard for IT professionals to manage a mass of demands of business applications (Stangarone, J., 2019) [15]. In such a situation, people who cannot get solutions from the IT department or IT professionals would look for third-party solutions without the oversight of the IT department, which is known as "Shadow IT" (Stangarone, J., 2019) [15]. Shadow IT can endanger an organization's IT security and privacy since the organization will have no knowledge and control of the applications such as implementation details, data management, and IT security threats (OutSystems, 2019) [7]. Low/No-Code development platforms, authorized by IT personnel or IT department, can help solve the risks brought by Shadow IT. Users can build needed solutions on the platforms without disturbing IT personnel constantly. Since the IT department controls the data and applications, security and privacy safety are guaranteed (Stangarone, J., 2019) [15]. Security concerns about citizen development were similar to those about Shadow IT (OutSystems, 2019) [7]. Low/No-Code development platforms can address the concerns in the same way we discussed above (i.e., the IT department can govern the citizen development applications) (OutSystems, 2019) [7].
If each component or building block in Low/No-Code platforms is secure, reusable, and optimized, the applications built with them should automatically be secure and optimized (OutSystems, 2019) [7]. According to respondents of Outsystems's (2019) survey, 64% of them noticed the scarcity of professional cybersecurity personnel and found that it is hard to hire them [7]. Using Low/No-Code platforms can save time  [7]. Thus, Low/No-Code can not only avoid the security risks but also lessen the heavy testing workload compared to the traditional development process.
d. Maintainability As Outsystems (2019) estimated, 65% of the application development projects were for maintenance, and the rest were for innovation [7]. Moreover, maintenance activities took approximately 75% of most IT resources of organizations (OutSystems, 2019) [7]. Outsystems (2019) found that organizations that use Low/No-Code development could have more projects for innovation (40%) instead of maintenance compared to those who were not using Low/No-Code development (35%) [7]. Low-Code platforms provide a sole and centralized environment for all aspects of application management, which reduces the complexity and difficulty of application maintenance since critical players in software maintenance (e.g., IT professionals, business professionals) can collaborate on the same platform efficiently ( [7]. We expanded several significant concerns about Low/No-code development as we did for advantages.

a. Limited Customizability/Flexibility
The visualized building blocks in Low-Code platforms are pre-implemented and fixed in most cases (Woo, 2020) [6]. Such inflexibility makes the applications less customizable than those developed by traditional coding development (Tay, N., 2021) [16]. It will be difficult and time-consuming to develop complicated or customized features or functionalities that are not provided on the Low-Code platforms (Tay, N., 2021) [16]. Implementing these desired features using codes and integrating them into Low/No-Code applications is an approach, but it lacks consistency and efficiency (Brocoders Company, 2021) [17]. Low/No-Code platforms usually outperform the traditional development process in implementing simple applications where the predefined components address common needs or processes well (Sarabyn, K., 2021) [18]. However, when it comes to projects such as highly customized applications, data science models, or data science workflows, Low/No-Code platforms are not customizable enough for these tasks (Sarabyn, K., 2021) [18].
b. Limited Scalability Most of the current Low/No-Code platforms are mainly used to develop small-scale applications, while they are seldom used for large-scale, complex, or crucial business applications due to their limited scalability (Sanchis et al., 2020) [1]. According to Rymer and Richardson (2015), the average runtime scale of applications reported by Low-Code platform providers was between 200 and 2,000 concurrent users [14].
c. Security Concerns Since most Low/No-Code platform users hardly do or cannot customize the applications, they must completely trust that the services do not generate vulnerabilities that cause bugs or data leaks (Oltrogge et al., 2018) [12]. For example, Mobincube, a paid Low-Code service, tracked users silently through Bluetooth low energy beacon without clearly declaring this in the terms and conditions (Oltrogge et al., 2018) [12]. If organizations are dependent on their Low/No-Code platform vendors, their data might be vulnerable to data breaches since data security and source code are not fully controlled by organizations (Tay, N., 2021; Oltrogge et al., 2018) [12] [16]. Moreover, if the platform vendors wind up, there will not be further security updates, and organizations cannot fix new security flaws later (Tay, N., 2021) [16].
d. Vendor lock-in Warren (2018) defined vendor lock-in as a customer's dependency on a vendor for their products and services, which makes it difficult for the customer to switch to another vendor [19]. In our context, the concern is that organizations will have vendor lock-in with Low/No-Code platform providers. As an organization invests more in an individual Low/No-Code platform provider, the organization will cost more and be more complicated for switching to another platform (Tay, N., 2021) [16].

III. CURRENT LOW/NO-CODE DEVELOPMENT PLATFORMS
In the Low/No-Code development industry, besides many emerging LNCD start-ups, tech companies like Microsoft, Alibaba, Salesforce, and Oracle have their own Low/No-Code development platforms (Woo, 2020) [6]. In this section, we analyze several major LNCD platforms in the market for their usage, features, and impacts on digital transformation. According to the study of Kulkarni (2021) on industry demographics of top LNCD platform vendors, we noticed that 20% of Microsoft users were in the manufacturing industry, 40% Appian users in the financial services industry, and 32% Mendix & 30% Salesforce users in services industry [9]. It shows that Manufacturing, Finance, and Services are the three primary industries that utilize LNCD platforms (Kulkarni, 2021) [9]. For the geographic demographics data of those vendors, 49% Appian and 52% users were in North America, 63% Mendix and 50% Outsystems users were in Europe, Middle East, & Africa, and 37% & 26% Microsoft users were in North America & Asia/Pacific, respectively (Kulkarni, 2021) [9].
Microsoft PowerApps is the LNCD platform provided by tech giant Microsoft. It is integrated with many Microsoft services such as Microsoft Office 365, Microsoft Azure, Microsoft Teams, and so on. It can be used for developing automated business applications by connecting Microsoft services in a workflow (Alsaadi et al., 2021) [11].
Salesforce provides a cloud based LNCD platform that uses Lightning Framework to build business applications more efficiently at a lower cost (Alsaadi et al., 2021) [11]. It gives many customization options for users, such as themes and colours, and those customizations can be reused, making company branding more straightforward without coding (Alsaadi et al., 2021) [11]. It was named a leader for LNCD platforms by Gartner in 2019 (Duffy, 2019) [5].
The LNCD platform of Mendix accelerates application development as other LNCD platforms do. It is outstanding among competitors because it values business & IT cooperation for refining business logic (Alsaadi et al., 2021) [11]. The platform divides the design environment for citizen developers (an environment called Mendix Studio) and professional developers (Mendix Pro) for better collaborations between departments by providing suitable tools for people in different departments. Stakeholders can also cooperate with developers on the platform to provide in-time feedback to boost development and innovation (Alsaadi et al., 2021) [11]. It also has a built-in AI assistant that checks errors and gives suggestions regarding the application's quality, maintainability, and scalability (Alsaadi et al., 2021) [11]. Such AI and ML integration in the platform can give novice developers real-time feedback to better learn the platform and application development.
Appian is smaller than many contestants in scale, but some of its customers are government agencies (Alsaadi et al., 2021) [11]. It is considered for the capabilities of building complicated business processes and applications that require advanced automation and analysis (Alsaadi et al., 2021) [11]. It also has an AI & ML guide integrated to give users immediate suggestions during the development.
We notice that most platforms integrated AI and ML technologies to give real-time recommendations during the development for making up some users' lack of programming skills. The LNCD platforms providers with AI are usually more competitive than others (Alsaadi et al., 2021) [11] since it enhances user experience and reduces concerns about LNCD platform usability. Though current LNCD platforms and technology have defects and limitations (Woo, 2020) [6], we can see the industry is rising, and they are conducive for application development in many cases.

IV. PROSPECT IMPACT ON SOFTWARE DEVELOPMENT
Chris Wanstrath, the CEO of GitHub, once said, "The future of coding is no coding at all." (Peterson, 2017) [21]. Chris Wanstrath claimed that automating the whole development process can make coding easier so that people can focus on the high-level strategies, designs, and architectures of software (Peterson, 2017) [21]. GitHub has plentiful code repositories and troubleshooting forums (Peterson, 2017) [21], which could be used for training AI & ML that gives real-time coding suggestions and error checking. Moskal (2021) argued that Low/No-Code programming is deemed as the fourth generation of programming, and it is also known as declarative programming [13].
However, Thomas Stiehm, the CTO of Coveros, had a contradictory opinion "Low-code is not the future of code. It certainly has a place in the future and will be leveraged to make many applications. It will not replace other ways of creating software because low code breaks down when the solution's complexity increases. We saw the same thing with Visual Basic in the '90s. VB was valuable, and a lot of software was written in VB. In the end, it was the complexity required by some applications that caused VB to break down and no longer be a good solution. Low code will be the same." (Brocoders Company, 2021) [17].
It is true that Low/No-Code development has its limitation and defects, but the analogy between Low/No-Code and VB is inappropriate since VB is an actual product, but Low/No-Code is a high-level concept. People can build their own variation upon a concept but not upon an existing product. For the argument that Low/No-Code cannot create high complexity solutions, we have seen companies such as Appian, Mendix, and Outsystems manage the complex applications well and innovatively. We have also seen the utilization of start-of-theart AI & ML technologies make LNCD platforms more intelligent and more robust. The defects we discussed before, such as limited scalability and security concern, they can be addressed as LNCD platforms become robust: (1) limited scalability   [8]: both runtime scalability (the capability to increase the capacity of deployed LNC apps and to provide fast user experience for both large numbers of users and heavy computation) and dev-time scalability (the capability to use LNC for numerous business requirements, projects, and developers) are proven to be solved in Outsystems' platforms; (2) security concern (Warren, 2018) [20]: Warren argued that if LNCD platforms are robust & well-structured, Low/No-Code applications should be secure by its nature (just as we discussed in Benefits sub-section). Therefore, for Low/No-Code to be best utilized for digital transformation or even to change future software development processes, LNCD platforms vendors must improve the flexibility, scalability, security, and other limitations so that people can accept this new technology without concern.
V. CONCLUSION Organizations' needs for digital transformation provide a stage for Low/No-Code development to show its worth. As digital transformation proceeds, the business application requirements will become more complex and specific. Though LNC has benefits that allow organizations to respond to trends in the industry agilely, they need more flexibility and customizability on the LNCD platforms. LNC provides secure building blocks that can be used for creating secure applications, but data breaches and lack of access to source code raise security concerns. Although there is little or no code to maintain and maintain LNC applications should be easy, vendor lock-in is a problem when the providers no longer support the platforms. Such contradictions show that LNCD could be conducive and show space for LNC technology to improve.
After analyzing current leading LNCD platforms in the market, we found that AI & ML is a key to improving current LNC technology. It is also a key for Low-Code converting to No-Code. As Chris Wanstrath prospected, in the future, people can focus on high-level software prototyping and designing instead of writing lines of code and wasting much time on implementation details. Such a future will come when Low/No-Code technology has wonderfully collaborated with robust coding AI & ML technologies. Thomas Stiehm compared LNC with VB and wanted to conclude the future of LNC should be the same as the one of VB. The conclusion is superficial and unlikely to happen (at least not in the way Thomas predicted). LNC platforms have many potential users, including children, students, professional developers, and non-IT-professional employees. Since it has such a wide range of users, the community should also be large-scale. User community ensures that it will be constantly refined and improved for users' needs. VB did not have such a wide range of users and use-cases, so LNC is not in the old path of VB.
Low/No-Code Development emerged only a few years ago, the adoption rate is rapidly growing, which indicates an optimistic prospect. Researchers around the world should do more research and assessments to solve the limitations and issues with current LNC technology. Organizations can cooperate with LNC platform providers to improve their platforms. It is not only for the providers but also for organizations to have a better user experience. LNC platform vendors should continuously research and address limitations by studying competitors' work and seeking to combine the latest technologies with the platforms.
In conclusion, based on our analysis in each section, Low/No-Code Development will play a crucial role in digital transformation and cause a turnaround in the software development industry.


Wireless Channel Modelling for Identifying Six Types of Respiratory Patterns With SDR Sensing and Deep Multilayer Perceptron

Contactless or non-invasive technology has a significant impact on healthcare applications such as the prediction of COVID-19 symptoms. Non-invasive methods are essential especially during the COVID-19 pandemic as they minimise the burden on healthcare personnel. One notable symptom of COVID-19 infection is a rapid respiratory rate, which requires constant real-time monitoring of respiratory patterns. In this paper, Software Defined Radio (SDR) based Radio-Frequency sensing technique and supervised machine learning algorithm is employed to provide a platform for detecting and monitoring various respiratory: eupnea, biot, bradypnea, sighing, tachypnea, and kussmaul. The variations in Channel State Information produced by human respiratory were utilised to identify distinct respiratory patterns using fine-grained Orthogonal Frequency-Division Multiplexing signals. The proposed platform based on the SDR and the Deep Multilayer Perceptron classifier exhibits the ability to effectively detect and classify the afore-mentioned distinct respiratory with an accuracy of up to 99%. Moreover, the effectiveness of the proposed scheme in terms of diagnosis accuracy, precision, recall, F1-score, and confusion matrix is demonstrated by comparison with a state-of-the-art machine learning classifier: Random Forest.

emergence of new variants in distinct parts of the world, the vaccine's effectiveness is at utmost concern. COVID-19 has been linked to more than 3 million deaths, according to the recent figure by World Health Organization (WHO) -https://covid19.who.int. Fever, flu, ageusia, cough, and lungs failure due to respiratory disorders are the most common symptoms of the virus, which spreads primarily by human-to-human contact. Governments all over the world are seeking to stop the epidemic from spreading by imposing frequent lockdowns, which is wreaking havoc on the economy and private businesses [1].
The novel variants of COVID-19 are directly targeting human lungs, consequently resulting severe damage towards the respiration. The average human respiratory rate for an adult at rest is between 12 and 20 breaths per minute, and it is irregular if it is less than 12 breaths per minute or more than 20 breaths per minute [2]. Respiratory rate that are abnormal may be sluggish, shallow, rapid, intense, or a hybrid of these. Figure 1 depicts the six diverse human respiratory or breathing patterns: eupnea, biot, bradypnea, sighing, tachypnea, and kussmaul. Eupnea is a regular respiratory with a normal rhythm and frequency caused by a healthy lifestyle, while biot is an intense respiratory with slow intervals of no breaths engendering by spinal meningitis or concussion  (head injury). Bradypnea is a sluggish and shallow respiratory resulting from concussion, sleeping pills, stroke, or metabolic disorder. Sighing is respiratory stressed by recurrent intense breaths due to dyspnea, dizziness, or nervousness. Tachypnea is the opposite of bradypnea described as rapid and shallow respiratory as a result of anxiety, fever, stun, or exercise. Lastly, kussmaul is an intense and rapid respiratory pattern by virtue of diabetic ketoacidosis, metabolic acidosis, or renal failure. Table I lists the descriptions and causes of the various human respiratory patterns.
As described earlier, one of the key symptoms of the novel coronavirus is irregular or abnormal respiratory caused by the virus attack on lungs. It is of utmost significance to detect and identify the abnormal respiratory at the earliest stages in order to safeguard human lives. This paper focuses on the detection and diagnosis of abnormal human respiratory owing on COVID-19 through reliable non-contact wireless techniques merged with intelligent artificial intelligence algorithms. The advancement of universal, contactless, and wireless sensor technology to track everyday activities is gaining popularity everyday. Recently, various methods for monitoring human health and vital signs such as heart rate, have been established. Smart watches, portable sensors, Doppler RADAR, ultra-wideband RADAR, and frequency modulated carriers are some of the examples of it.
The rest of this paper is structured as follows: Section II provides a recent literature review towards non-invasive technology. In Section III, the details regarding proposed platform is provided. Section IV presents the experimental results and analysis. Finally, Section V provides concluding remarks.

II. LITERATURE REVIEW
In this section, we have discussed distinct literature about non-invasive or non-contact sensing technologies and how they were utilised to detect and monitor various human activities and health conditions including symptoms of COVID-19 such as abnormal respiratory and heart rate.

A. Activity Monitoring Using Non-Invasive Technology
Authors in [3] utilised an ambient RADAR sensor to recognise various human activities in interior spaces and this system was able to classify a wide range of human activities. In [4], authors acquired RADAR spectrogram data to distinguish and categorise different types of falls in elderly humans. In [5], for fifteen distinct operations in the kitchen environment, a low powered RADAR sensor was employed. Authors in [6] developed a non-invasive passive detection system on a dynamic speed platform to recognise diverse human activities using commercial Wi-Fi. In [7]- [10], authors built a "Through the Wall" presence detection device for people that uses Wi-Fi signals to extract channel frequency response. A Wi-Fi-based gesture recognition system was designed that analyses fluctuations in Channel State Information (CSI) of Wi-Fi signals to monitor and identify distinct hand movements [11].
In [12], authors presented a methodology for identifying various eating activities utilising Wi-Fi signals, while the authors [13] developed a system for user identification for mobile devices utilising Wi-Fi technology. Using RF-based sensing, authors in [14] constructed a sleep guardian platform by integrating signal processing, machine learning, and edge computing. In [15], a Wi-Fi run system is built in the activity area for step estimation utilising CSI dynamics, whereas a Software Defined Radio (SDR) based non-contact system was created in [16] to recognise various human actions like standing, running, crawling, and so forth. Moreover, the authors in [17] generated a scheme based on SDR technology to hear various types of human speech, whilst [18] employed SDR technique to implement a whole house gesture recognition system.

B. Health Monitoring Using Non-Invasive Technology
Authors in [19] employed the passive doppler RADAR device to detect and classify distinct human respiration. Similarly in [20], human respiratory detection scheme was designed using a passive Doppler RADAR platform. In [21], Wi-Fi signals are used to monitor vital signs and recognise distinct body positions while sleeping. Authors in [22] and [23] employed the C-Band sensing techniques for various health monitoring concerns such as respiratory detection, tremor, and chronic obstructive pulmonary disease warning, whereas in [24] Res-Beat scheme was developed to track the rate of respiration.
In [25]- [27], authors developed a system based on S-band sensing techniques for a variety of health monitoring concerns, including seizure episode identification, cerebellar dysfunction patients' mobility evaluation, and pill rolling evaluation. Authors in [28] exploited the SDR-based technology to categorise various human exercising activities. Recently, in several literature, various machine/deep learning algorithms have been effectively applied to predict and diagnose COVID-19 symptoms using "Radio-graphic Imaging" [29]- [33].

III. PROPOSED SCHEME A. System Model
The scheme designed for this research work is made up of desktops that are utilised to run the SDR software in Laboratory Virtual Instrument Workbench (LabVIEW). The Universal Software Radio Peripheral (USRP) model "2922" is employed for SDR technology's general Radio-Frequency (RF) capabilities and omni-directional antennas for CSI capture. By observing small-scale motions in the wireless channel and obtaining fine-grained CSI, our system is able to recognise and categorise distinct respiratory patterns. The transmitter's RF signal travels via many multipaths to reach the receiver in an interior environment. This signal comprises data on environmental variables. The environment here is defined as the physical space that contains human aspects such as human postures, respiratory patterns, as well as environmental characteristics [35].
When a human is present in physical space, the reflection or diffraction of signals from its body creates a supplementary channel. As a result, the influence of human movement (either small or big) is recorded on the signal propagation and reported in the form of CSI on the received signals. Subsequently, the data from CSI can be utilised to identify distinct respiratory patterns. The USRP transmitter continually emits wireless signals with a certain frequency and the USRP receiver, on the other hand, receives these transmitted signals. Meanwhile, respiratory activity causes a minute deviation in the chest and abdomen, resulting in a shift in the signal propagation route recorded by the received signals in the CSI form. As illustrated in Figure 2, this non-invasive SDR-based scheme consists of three key functional blocks: the transmitter, radio or wireless channel, and receiver.
1) Transmitter: The transmitter is made up of two parts: the desktop and the USRP device. Pseudo random data bits are generated in the transmitter and transferred to quadrature amplitude modulation symbols or signs. These signs are then separated into two streams. In each parallel framework, reference data signs are concatenated. These reference signs are useful for the channel estimate on the receiver side. Every framework has zeros at the borders and one zero at DC. The Inverse Fast Fourier Transform (IFFT) function is used to convert frequency-domain signals into time-domain signals after zero padding. Each framework at the starting has a Cyclic Prefix (CP), which is created by replicating the last one-fourth point. This addition of CP will aid in the elimination of frequency and time offset at the receiver side. The synthesised data from the host desktop is transferred to the USRP device at a rate of "20 MS/s" over gigabit ethernet. The USRP uses a Digital Up Conversion (DUC) to convert the incoming signal to "400 MS/s", and then uses a digital-to-analog converter to transform the signals into analogue. The resulting analogue signal is blended up to the specified carrier frequency after passing through a low pass filter with a "20 MHz" bandwidth. This signal is then sent to an amplifier transmit, where the strength can be assorted from 0 to 30 dB. The signal is then broadcasted using an omni-directional antenna.
2) Radio Channel: In this part of the scheme, an indoor radio channel is employed to gather information on distinct respiratory patterns due to minute human motions while breathing. The multi-path signals created by human body motions in between the two omni-direction antennas comprise the CSI signal.
3) Receiver: The signal is initially obtained by the USRP equipment through the omni-directional antenna on the receiving side. After passing this signal via a Low Noise Amplifier (LNA) to minimise the noise factor, it is then routed via a Drive Amplifier (DA) to alter the gain. The resulting signal is blended into a base-band complex signal utilising the Direct Conversion Receiver (DCR). The signal is then sampled at "100 MS/s" by a two channel analog-to-digital converter after passing through a Low Pass Filter (LPF) with a "20 MHz" bandwidth. This digitised complex signal is subsequently sent to a Digital Down Converter (DDC), which mixes, filters, and decimates it to a user-specified rate. Finally, at up to "20 MS/s", this down-converted signal is delivered to the host desktop via gigabit ethernet connection. The receiver host desktop not only eliminates CP from each framework, but also utilises the "Van de Beek" algorithm to eliminate frequency and time offset. The Fast Fourier Transform (FFT) is used to transform the time domain Orthogonal Frequency-Division Multiplexing (OFDM) instances into frequency domain OFDM instances once the CP is removed from each framework. The frequency domain signal's amplitude response is then extracted to determine distinct patterns of respiration.

B. Diagnosis Approach
The primary steps involved in the abnormal respiratory diagnosis approach are shown in Figure 3 and are explained as follows.
1) Data Acquisition: The data on respiration were collected in a laboratory setting, which illustration is presented in Figure 3. The experimental setup consists of two USRP (NI-2922), with a spacing of one metre between the USRP device and the human participant. Each participant was instructed to sit in a relaxed position with the least body movements. Both USRP devices are parallel to the participant's abdomen and situated at the same height. Table II lists the details of each of the five individuals who were instructed to practise different respiratory patterns.
Participant were instructed to do each respiratory pattern appropriately as per medical instructions before respiratory information was acquired. Each human subject in this study was instructed to perform six different respiratory: eupnea, biot, bradypnea, sighing, tachypnea, and kussmaul. A total of 150 experiments are conducted for six distinct respiratory Framework of the applied model for abnormal respiratory diagnosis.
patterns and lastly, six datasets are obtained from five human participants. Participants performed each respiratory activity for thirty seconds. To assure and obtain a greater degree of precision, comprehensive experiments are carried out.
2) Data Wrangling: After data acquisition, the data were processed in order to eliminate unwanted noise and extract important respiratory features. The obtained OFDM signal is exploited for fine-grained CSI extraction at the receiver end. The amplitude and phase frequency responses from the obtained OFDM signal can be acquired. However, only the amplitude frequency response is employed for further processing in this study. The respiratory activity is identified by following the acquisition of the amplitude frequency response for each respiratory activity. If the amplitude response closely resembles the real respiratory rate, it is approved; otherwise, it is rejected, and the individual is requested to repeat the respiratory pattern more effectively. The number of subcarriers, as well as the number of OFDM samples, are displayed in this amplitude response. The number of OFDM samples received is determined by a variety of parameters, including the amount of time it takes to complete each respiratory activity. a) Subcarrier selection: For each respiratory activity, the receiver acquires a set of 256 subcarriers. It is noted that the amplitude of every subcarrier reveals distinct sensitivity to respiratory patterns. To improve respiratory activity recognition, any subcarriers that are less sensitive to respiratory activity have to be removed. The variance of subcarriers is determined, and on this basis, all subcarriers with lower sensitivity to respiratory activity are eliminated, as shown in the data wrangling block of Figure 3. b) Outliers removal: Wavelet filtering is applied after subcarrier selection. As illustrated in the second block of the data wrangling process in Figure 3, the wavelet filter not only eliminates outliers from the raw data but also preserves crisp transitions. Soft heuristic threshold is used for wavelet filtering with scaled noise parameters with detail coefficients at level 4 using wavelet Symlets-5 (sym5). c) Refined data: A moving average filter with window size 8 is employed to refine the data further and eliminate high frequency noise not caused by respiratory activity, as depicted in Figure 3. Various respiratory patterns can easily be identified after conducting the afore-mentioned data wrangling processes.
3) Deep Multilayer Perceptron Classifier: After distinct layers of data processing and respiratory features extraction, at last the data were trained by Deep Multilayer Perceptron (DMLP) classifier. The DMLP is a supervised deep learning technique where a feedforward artificial neural network produces a number of outputs from a set of inputs. Several layers of input neurons are linked as a directed graph between both the input and output layers of the DMLP. Backpropagation technique is utilised by DMLP classifier in order to train the network. Substantially, a neural network linking several layers of a directed graph is a multilayer perceptron, meaning that the signal flows one way across the neurons. Each neuron has a nonlinear activation function besides the input neurons. The DMLP is commonly used to address problems that need supervised learning approach such as speech recognition, machine translation, image recognition, and anomaly detection [36]- [41].

IV. SIMULATION RESULTS AND ANALYSIS A. Respiratory Data
This section provides a detailed description about each respiratory pattern utilising SDR-based RF sensing. Five separate participants conducted each respiratory activity and each individual knew the features of all breath patterns through sufficient instructions and training before doing these diverse respiratory tasks. For a few times, each participant has been instructed to practise these patterns of respiratory and the outcomes for six distinct respiratory patterns are then achieved. In order to evaluate these respiratory patterns, the CSI amplitude response is utilised. Figure 4 displays the findings for six distinct respiratory activities and the amplitude of respiratory patterns in all subcarriers. Due to every activity across 3500 OFDM samples, changes in amplitude reaction are achieved. The outcome of each type of respiratory is discussed as follows.
1) Eupnea: Eupnea is a normal pace of respiratory and adults normally have 12-20 breaths per minute in the case of eupnea. The participants were asked to breathe properly and at a regular pace in order to obtain eupnea respiratory pattern. Figure 4(a) shows that there are 10 breaths each halfminute, which corresponds to the respiratory patterns depicted in Figure 1(a).
2) Biot: Biot is a deep respiratory practice that alternates with intervals of no respiration. The participants were asked to practise and perform this respiratory pattern and Figure 4(b) shows that deep respiratory were followed by breathless intervals, which corresponds to the respiratory patterns depicted in Figure 1(b).
3) Bradypnea: The bradypnea is a type of respiratory that is sluggish and shallow. The participants were asked to breathe more slowly than usual in order to acquire this respiratory. Figure 4(c) shows that six breaths were taken every thirty seconds, which corresponds to the respiratory patterns depicted in Figure 1(c).

4) Sighing:
Sighing is a type of respiratory pattern that includes numerous intense breaths. To acquire a sighing respiratory, the normal respiratory was disrupted by many intense breaths, as indicated in Figure 4(d), which corresponds to the respiratory patterns depicted in Figure 1(d).
5) Tachypnea: Tachypnea is characterised by rapid and shallow respiration process. The participants were instructed to breathe quicker than typical in order to obtain this respiratory pattern. Figure 4(e) shows that thirteen breaths were taken every thirty seconds, which corresponds to the respiratory patterns depicted in Figure 1(e).

6) Kussmaul:
The kussmaul is a respiratory that is both quick and deep. The rapid and intense breaths can be noted in Figure 4(f), which corresponds to the respiratory patterns depicted in Figure 1(f).

B. Results
We have recruited healthy participants with various age range and ask them to mimic the particular six breathing pattern, which were efficiently detected by the proposed model. Each respiratory dataset consisted of 3650 × 3500 observations or data points. Considering the six above-mentioned respiratory classes, the final dataset were composed of 6 × 3650 × 3500 data points. In each respiratory class, 50% of the data samples were used to train the machine learning classifier, whereas 25% of the data samples were used for validation purposes and remaining 25% for testing. In this  work, a multi-class classification technique was adopted to classify (or diagnose) each respiratory and the data samples were labelled accordingly.
To execute the simulations, the DMLP algorithm used in this study was programmed in Python. The "Grid Search Cross-Validation" methodology was adopted for the validation part of the dataset in order to optimize the hyperparameters for DMLP. This methodology uses the principles of fit and score to discover the appropriate parameters for training machine learning models. These parameters are provided in Table III. Moreover, using a single performance assessment metric for machine learning models is often not regarded as best practise. Hence, to evaluate the performance of the algorithms, five different metrics were used: confusion matrix, precision, recall, f1-score/f-measure, and diagnosis accuracy [43] (see Equation 1,2,3,4).

Di agnosi s Accur acy
= Number of r espir ator y di agnosed T otal number o f respirator y (1)

Precision = T rue Positives Predicted Positives
(3) In this work, we exploited two distinct machine learning classifiers: Deep Multilayer Perceptron (DMLP) and Random Forest (RF). The reason to choose two various classifiers is to evaluate the performance on different respiratory. Although DMLP achieved a slightly higher accuracy than RF, nevertheless both classifiers almost performed the same. Table IV shows the overall accuracy accomplished by the DMLP and the RF. Moreover, Figure 5 exhibits the confusion matrix for diverse respiratory classifications. As can be seen in Figure 5(a), DMLP has only 12 misclassifications of eupnea with biot respiratory class, whereas the biot class has merely 19 misclassified points with eupnea and 5 with bradypnea. This is due to the fact that these classes have highly similar structure than other classes. Rest of the classes such as bradypnea, sighing, tachypnea, and kussmaul have either 1 or 2 misclassified points, therefore resulting in accuracy up to 99%. Furthermore, Figure 5(b) demonstrates the performance of RF classifier. As can be noted, RF has slightly higher misclassified points than DMLP, nevertheless, RF resulted in accuracy up to 98%.

C. Future Work
There are certain limitations associated with this study, which we aim to overcome in the future research work. We would consider more realistic environment and conduct experiments in noisy environment and in different body postures. Furthermore, the proposed scheme can be utilised for a single subject at a time in a static and controlled environment. Apart from that, the experiments were not conducted on real COVID-19 infected patients due to several concerns. As a result, the future recommendations would be to add respiratory patterns of several subjects in a non-static environment, employing more advanced algorithms and utilising the SDR-based platform's versatility. Moreover, real-time data acquisition of COVID-19 infected patients shall be carried out in order to construct a more realistic model. Other than that, more respiratory patterns such as ataxic and cheynestokes shall be explored to enhance the system's reliability.

V. CONCLUSION
While in the midst of the COVID-pandemic, non-invasive strategies help minimise the burden on healthcare professionals, as well as require the least amount of involvement from affected individuals. Studies on recently diagnosed patients show that a COVID-19 infection affects respiratory or breathing patterns differently in comparison to flu or a cold. In some cases, COVID-19 infection is marked by an accelerated respiratory rate and that calls for constant monitoring of respiratory patterns. In this paper, a non-invasive or contactless SDR-based platform merged with intelligent machine learning algorithms is proposed. The system is designed for the detection and monitoring of primarily six distinct human respiratory patterns including normal and abnormal such as eupnea, biot, bradypnea, sighing, tachypnea, and kussmaul. The respiratory data employed for this study were acquired from five different subjects. Using fine-grained OFDM signals, the fluctuations in CSI caused by human respiration were used to detect distinct respiratory patterns. Then, using the Deep Multilayer Perceptron classifier, these respiratory patterns were effectively classified attaining accuracy of up to 99%. As a result, it can be stated that SDR-based Radio-Frequency sensing is a viable approach in an indoor setting for detecting and classifying several respiratory patterns linked to various illnesses, whether COVID-19 infection or any other disease.


Towards Interoperability of Entity-Based and Event-Based IoT Platforms: The Case of NGSI and EPCIS Standards

With the advancement of IoT devices and thanks to the unprecedented visibility and transparency they provide, diverse IoT-based applications are being developed. With the proliferation of IoT, both the amount and type of data items captured have increased dramatically. The data generated by IoT devices reside in different organizations and systems, and a major barrier to utilizing the data is the lack of interoperability among the standards used to capture the data. To reduce this barrier, two major standards have emerged: the Global Standards One (GS1) Electronic Product Code Information Service (EPCIS) and the FIWARE Next Generation Services Interface (NGSI). However, the two standards differ not only in the data encoding but also in the underlying philosophy of representing IoT data; namely, EPCIS is event-based, and NGSI is entity-based. Interoperability between FIWARE and EPCIS is essential for system integration. This paper presents OLIOT Mediation Gateway, now one of the incubated generic enablers offered by the FIWARE Foundation, that realizes the required interoperability between NGSI and EPCIS systems. It also demonstrates the applicability and feasibility of the Gateway by applying it to a real-life case study of integrating transparency systems used in a meat supply chain.

I. INTRODUCTION
Internet of Things (IoT) refers to the network of devices that can autonomously capture data, process them, and act on them. As the number of IoT-related devices and applications grows, as is the case of the agriculture and food (agri-food) sector [1], the communication between IoT systems has become increasingly complex. A major obstacle encountered by IoT adopters is the lack of interoperability among different systems and platforms. In fact, there are currently diverse IoT ecosystems, and they tend to use their own standards and formats for sharing and storing data [2], [3]. There are The associate editor coordinating the review of this manuscript and approving it for publication was Liang-Bi Chen . currently more than 450 IoT platforms on the market [4], which makes the IoT ecosystem highly fragmented.
While the opportunities provided by data generated by IoT devices are numerous, lack of interoperability creates a major barrier. For instance, realizing transparency systems in the agri-food sector requires sharing data captured by IoT devices across the supply chain operators, including farmers, food processors, third parties (such as logistic companies), and retailers. The interoperability of the data across the collaborating food operators is an essential requirement for using IoT data for transparency purposes.
Current efforts in standardizing IoT data and platforms has resulted in two major standards: the OMA/ETSI NGSI standard [5] and GS1 EPCIS standard [6]. In the agri-food sector, some food operators and retailers are adopting the EPCIS standard, while others are considering the NGSI standard. More specifically, various studies [7]- [10] have shown that NGSI platforms are more suitable and preferred by food operators that share real-time sensor data to maintain and manage resources. The EPCIS standard, on the other hand, is preferred by businesses that focus on tracking-and-tracing of products. For instance, Metro Group [11], one of the leading retailing companies in Europe, has adopted the EPCIS standard for its traceability system. The IBM food trust [12] platform, which is used by Walmart, also uses the EPCIS standard to capture traceability data. This makes the two standards complementary to each other, and the interoperability between them is crucial for a smooth end-to-end sharing of data among food operators.
Interoperability between these two standards is challenging because they differ not only in data encoding but also in the underlying philosophy of representing IoT data; namely, NGSI is entity-based and EPCIS is event-based. The entity-based approach has been studied in the context of business processes modeling, where business entities, which the activities act upon, are the key constituents of business processes. Business process models emphasize on the states and the transition between the states of the business entities [13]. The state transitions of a business entity, i.e., entity's life cycle [14], however, is better captured by event-based modeling because event information primarily captures the identity of the entity, the specific time and location of the event and add only the necessary contextualization information, relegating the remaining details about the entity to a separate master data repository.
The differences between the two standards' data models are schematically depicted in Fig. 1 using a simple example of the life cycle of books in a library. Fig. 1(a) shows the details about books as an E-R diagram-which is a suitable representation formalism for entities. Fig. 1(c) shows the same data as an event-model (comparable to the state-transition diagram [15]). This approach captures transparency information directly and is more suitable for representing tracing and tracking information, and for that reason, it has been adopted as an international standard for transparency. The former is the basis for the NGSI standard adopted by FIWARE, and the latter is the basis for the EPCIS standard adopted by GS1.
This work provides a solution to support interoperability between the NGSI and EPCIS through a Mediation Gateway, as shown in Fig. 1(b). This study considers a one-way translation from NGSI to EPCIS, which is most needed. Therefore, the Mediation Gateway needs to derive events from entity-based data. These, in turn, requires data processing and integration of the two different sets of APIs provided by NGSI and EPCIS. This paper's remainder is organized as follows: Section II illustrates the works related to the present study and the information about NGSI and EPCIS data models, and their architecture and reference implementation. Section III explains the proposed technique for the interoperability of the event-based model with an entity-based model. Section IV presents the implementation scenario of the interoperability platform on a pig farming use case. In section V, the authors present the evaluation and discussion. Finally, concluding remarks are made in section VI.

A. IoT INTEROPERABILITY
In general, IoT interoperability can be categorized into four levels [16]: technical interoperability, syntactic interoperability, semantic interoperability, and organizational interoperability. This study can be classified as semantic interoperability, and thus we focus on related works on semantic interoperability.
Even though there are plenty of open IoT platforms available on the market [2], [17], only a few have focused on the integration of these platforms [18]- [23] and all of them focused only on entity-based platforms. For instance, Kovacs et al. [18] annotate OneM2M ontologies with semantic information to simplify the translation from OneM2M data to NGSI data. Similarly, An et al. [24] used a similar approach to translate data from NGSI to the oneM2M format. Sotres et al. [21] describe a smart parking use case by applying two entity-based platforms' interoperability. There is no previous work that tried to bridge entity-based(NGSI) with event-based(EPCIS) IoT platforms to the best of our knowledge. Moreover, this work is the first to introduce the entity-based life-cycle modeling to identify events for the IoT.
The only study we found in the literature that resembles ours is the work done by Overbeek et al. [25]. It proposed Event-Based data architecture for generating events by applying complex event processing from process and service layers of information systems. Our work differs from this work FIGURE 2. NGSI-LD core meta-model and the cross-domain ontology (adapted from [30]). The meta-model is composed of entity, relationship, and property, as shown in the middle. At the bottom, location and temporal entities are depicts as an example of cross-domain ontology.
because, unlike [25], our main objective is interoperability between two open standards. Moreover, the Mediation Gateway, in general, is different from complex event processing [26]- [28] since the former does not process event patterns over time. Instead, it only contextualizes the information received, constructs the event, and registers in the format of EPCIS.

B. NGSI
One of the standards currently promoted in Europe and used in large European research and innovation projects is the FIWARE NGSI standard. FIWARE is a foundation, but it also refers to a set of tools, called generic enablers, for supporting the development of Smart City, Smart Agri-Food, and Smart Industry applications. FIWARE is developed within the European Future Internet Public Private Partnership (FI-PPP) initiative [29].
The NGSI standard was first defined by the Open OMA in 2012 [30]. It is then enhanced by FIWARE, resulting in NGSI-v2 [31]. Finally, it evolved and standardized in November 2018 into the new NGSI-Linked Data (NGSI-LD) version of the standard [30] by the ETSI 1 Industry Specification Group for cross-cutting Context Information Management (ISG CIM). 2 The NGSI-LD Information Model is based on the ''Core Meta-Model'' as represented in the central part of Fig. 2, and that corresponds to a formal specification of the foundation classes presented in the NGSI standard [5]. The upper part of the figure presents the classes that are used to represent context with a focus on the mapping of the NGSI-LD classes (also called resources) with the standard Resource Description Framework (RDF 3 ) data model [32].
The prominent and most widely used implementation of the NGSI standard is the FIWARE Orion Context Broker [33] developed by the FIWARE Foundation in the Connecting Europe Facility (CEF) [34] initiative. The Orion Context Broker is the central part of the FIWARE platform and uses as a Representational State Transfer (REST) API [35] to capture, update, query, and subscribe to changes on context information.

C. EPCIS
The EPCIS standard [6] defines a data model along with a capturing and querying interface. Its Abstract data model defines two kinds of data: Event data and Master data, as depicted in Fig. 3. Event data is generally used to capture dynamic data from business processes in the form of EPCIS events. Master data, on the other hand, is the additional data that provides the necessary context for interpreting the event data. Based on the definitions, it is up to the industries (along with end-users) to model their real-world business information as EPCIS events and master data.
EPCIS uses multiple vocabularies to model processes involving physical or digital entities that happen in the real world. To create a common understanding of vocabularies' semantics among parties who exchange EPCIS events, GS1 published the Core Business Vocabulary (CBV) standard [36]. The standard defines different vocabulary structures and specific values of some of the vocabularies used during the construction of events.
EPCIS events are basically designed by annotating four pieces of contextual information that can describe business event and they are commonly referred to as the four dimensions of an EPCIS event, namely: the ''What'', ''When'', ''Why'' and ''Where'' of an event. The ''What'' dimension contains one or more unique identifiers for physical or digital objects (classes). The ''When'' dimension captures the moment in time at which the EPCIS events occurred. The ''Where'' dimension of the event describe where the event took place. The ''Why'' dimension denotes a specific activity within a business process of the event. More additional information can also be included to the event.
According to the GS1 Software certification program [37], there are currently more than 20 certified implementations of the EPCIS standard, including major software systems of SAP, IBM, Oracle, and Microsoft. IBM implemented EPCIS as part of its IBM Food Trust [12] project to enable traceability of food. Oliot-EPCIS [38] and Fosstrak [39] are some of the standard's well-known open-source implementations. The European EPC Competence Center (EECC) has implemented its commercial EPCIS 1.2 compliant solution ''EPCAT.''

III. OLIOT MEDIATION GATEWAY DESIGN AND IMPLEMENTATION
This section introduces the OLIOT Mediation Gateway, which was designed and developed by the authors and has now become part of the generic FIWARE enablers [40]. As depicted in Fig. 4, the Mediation Gateway enables automatic interoperability between the FIWARE Context Broker (the widely used implementation of the NGSI standard) and the EPCIS system (in this study, the EPCAT and OLIOT implementation of EPCIS from EECC and KAIST, respectively, were used to test the Mediation Gateway).
The Context Broker is used to receive data from IoT devices and construct NGSI compliant entity data. The data received from an IoT device is used to create a new NGSI entity or update the state of an existing NGSI entity. The Mediation Gateway receives the updates passively as notifications or actively queries for updates, and when Gateway receives NGSI entity data, it generates EPCIS events based on it. The EPCIS system captures the EPCIS events sent by the Mediation Gateway and stores them in an EPCIS repository so that any accessing application can access the events via the EPCIS standardized query interface.
The Context Broker provides synchronous and asynchronous interfaces to access entities generated by a context producer. The Context Broker has four components [41]: Entity Manager, HyperText Transfer Protocol(HTTP) Request Receiver, HTTP Response Sender, and a Repository of data about entities and subscriptions (left side of Fig. 4). When a context producer publishes an entity to the Context Broker, the Entity Manager receives the data via the HTTP interface and stores it into the repository. Similarly, subscriptions are stored in the repository by the Entity Manager. Upon any update of entities' attribute values or when a new entity is published, the Entity Manager sends notifications to the subscribers (in this case, the Mediation Gateway) via its HTTP response sender interface. From the perspective of the Context Broker, the Mediation Gateway is a context consumer.
The EPCIS system provides, just like the broker, both synchronous and asynchronous interfaces to capture event data. The modules of an EPCIS system in implementations like Oliot-EPCIS [38] and EPCAT [42] can be grouped into four parts: EPCIS Capturing Interface, EPCIS Repository, EPCIS Subscription Manager, and EPCIS Querying Interface (as shown right side of Fig. 4). The Capturing Interface validates the incoming events according to the standard schema and sends them to the EPCIS repositorythe repository stores EPCIS event data. The repository also contains master data and subscription information. The Subscription Manager manages scheduled and triggered queries. Applications that want to get data from the EPCIS system interact via the Querying Interface. From the perspective FIGURE 4. FIWARE-EPCIS mediation gateway. VOLUME 9, 2021 of the EPCIS system, the Mediation Gateway is an EPCIS Capturing Application.
The Mediation Gateway (central part of Fig. 4) translates the information captured by the Context Broker in the form of NGSI entity data and capture into EPCIS events. To do so the Mediation Gateway has five components: Subscription Manager, Triggering Manager, Event Factory, Temporary Entity State Repository, and Event Publisher modules. These components are described below.

A. SUBSCRIPTION MANAGEMENT
The ''Subscription Manager'' manages asynchronous communication between the Context Broker and the Mediation Gateway. It opens a subscription endpoint corresponding to each entity in the Context Broker. Since NGSI entities are grouped by their domains, the endpoints are designed hierarchically and start with a domain name followed by entities. This helps to uniquely identify each subscription endpoint. The subscription Uniform Resource Locator (URL) is also designed to accommodate future NGSI models. It is composed of the context address, the NGSI version, application data domain, and a specific entity within the application data domain; {FIWARE_context_adress}/{NGSI_version}/ subscription/{application_data_domain}/ {entity_name}. This makes the Mediation Gateway design extendible not only to new domains but also to new NGSI standards. Upon any notification of entities attribute's value change, the Subscription Manager receives data from the Context Broker and passes it to the Event Processor module.

B. TRIGGER MANAGEMENT
The ''Triggering Manager'' of the Mediation Gateway handles synchronous communication with the Context Broker. When an entity's status needs to be checked periodically or upon a status change of other related entities, the Triggering Manager triggers a request for the entity's status via a request-response interface. Whenever there is a state change, the Context Broker captures the information by updating the specific entity's attribute values in real-time. In NGSI, the ability to retrieve historical data is limited. Entity's attribute's value reflects only the latest update.

C. EVENT FACTORY
The ''Event Factory'' module receives data from the Subscription and Trigger Manager, determines if the status of entity has changed, and if the status has changed, produces an EPCIS event. The change in status, and thus the creation of an event, is identified using Entity Life-cycle History (ELH) modeling [15], [43], [44]. An ELH is a model that integrates entities (objects) with process to make an information system [14]. To construct an ELH model, first, all entities are identified from the E/R model representing the NGSI data model (for instance, the E/R model books ELH showed in Fig. 1). Secondly, all process steps (real-world transactions) that have a net effect of changing the state of an entity (e.g., acquire, catalog, sell, etc.) are identified-data flow analysis is used to identify the process steps [44]. Finally, events are identified by applying each process step to each entity. The effect of applying the process steps can be categorized as Create, Read, Update and Delete (CRUD) operations. Events are considered if only the process steps have resulted in an entity state change. This can be (using the example of the books life cycle), for instance, the process step acquire has a Create (C) effect on the entity Book; catalog has an Update (U) effect; sell has a Delete (D) effect. The creation of EPCIS events is triggered every time a ''significant state change'' (attribute's value change) occurs in the entity life history of the NGSI entity data model. Thus, this module's main functionalities are to map the entity status change with the corresponding events and annotate the events with the context information as defined in EPCIS.
An entity's attribute value change in the NGSI data model can cause the generation of one of the following three event types: Simple Translation, Simple Event, or Complex Event. When the change of the attribute value simply describes the status of the entity under consideration, the change can be directly translated into events, i.e., simple translation. For example, when there is a simple sensor reading in a building, the change can be easily translated to the creation of an event. This kind of translation can be configured to be triggered periodically or when the change meets certain conditions. Simple event generations are like simple translation in the sense that both occur when there is an update of one or more attributes within a single entity. But in the case of simple event generation, the change of attributes must result in a change in context. For example, growth events can be generated from a weight change. Lastly, events that are generated due to an update of attributes from multiple entities are referred to as complex event generation. In this case, the entities can be generated by multiple IoT devices. For example, data from sensors attached to an animal and sensor information from the environment can be combined to generate alerts about the health status of the animal.
During the construction of the events, each event is contextualized, which means the four key dimensions of the EPCIS event are determined, which are: object(s) that are the subject of the event (''What''), the date and time (''When''), the location at which the event occurred (''Where''), and the business context (''Why''). These four sets of data fully describe what happened in that specific time and location and fully describe the entity's specific life cycle.

D. TEMPORARY ENTITY STATE REPOSITORY
The ''Temporary Entity State Repository'' (Redis, 4 an in-memory database, is used in the current implementation) is used to store the previous entity state temporarily. It is important to store entity states in order to determine if a significant state change has occurred. For instance, in animal farming, to check a significant weight change and generate a growth event, an animal's last known weight needs to be stored.
The use of in-memory database instead of the traditional database speeds up the translation process.

E. EVENT PUBLISHER
The ''Event Publisher'' module publishes the generated event, which means the data is translated into the EPCIS document standard, which is the EPCIS eXstensible MArkup Language (XML) format, and pushed via its standard interface.
The Mediation Gateway also captures or updates EPCIS master data whenever there is any change and is also responsible for mapping the local identification system used in FIWARE into the globally managed GS1 identification system.

IV. USE CASE: PIG FARMING
In this section, the case study validation is presented. In the first subsection (section IV-A), the use case is described in detail. The use case comes from a pig farm where the IoT systems are deployed, and data is gathered. Then the NGSI data model for entities of the case study is presented in section IV-B. Next, the corresponding EPCIS event model is presented in section IV-C. Finally, the application of the Mediation Gateway to convert the NGSI data into EPCIS events is presented in section IV-D.

A. THE USE CASE
The case study used in this study is one of the 33 IoT use cases of the Internet of Food & Farm 2020 (IoF2020) project. The case study is entitled ''Pig Farm Management'' and demonstrated IoT devices' application in precision pig farm management [45]. The test farm is located in Belgium and is part of the ILVO 5 research institute pig test farms. The ''Pig Farm Management'' use case aimed to innovate pig farm management through monitoring feed and water consumption, growth, and health parameters of an individual or groups of pigs.
Several IoT sensors were deployed at the test farm in order to collect real-time data. Fig. 5 shows the setup of the experimental compartment at the farm. The compartment contained 120 fattening pigs equally divided into eight pens. There was an equal number of male and female pigs, and a pen contained either exclusively male or exclusively female pigs. Each pig was identified uniquely using Radio Frequency IDentification (RFID) tags attached to both ears for ease of reading. To measure how much fodder was consumed by each pig, the PigWise 6 feeder and the Nedap 7 feeding station (feeder and feeding station, respectively, in Fig. 5) were used. The PigWise system uses High Frequency (HF) RFID tags for the identification of the pig that is eating [46]. While the Nedap feeding stations (pens 1, 3, 5, and 7) use Low Frequency (LF) RFID for the same purpose. The Nedap 5 https://www.ilvo.vlaanderen.be/ 6 https://ec.europa.eu/eip/agriculture/en/find-connect/projects/pigwise 7 https://nedap.com/ feeding station weighs the feed portions delivered to each pig and derives the amount of feed consumed. The PigWise feeder does not measure feed intake; only feeding patterns were registered. Furthermore, the PigWise drinker system was used to register water flow and drinking patterns [47]. The drinker uses a flow meter to measure the amount of water consumed and the drinking patterns. Two different solutions were used to weigh pigs: the one provided by the Nedap system (weighing scale in Fig. 5) and a regular scale found outside of the pens. The Nedap feeding stations weigh each pig while they are in the station, while the regular solution was used when the pigs are entering or exiting their pens. Finally, the climate of the pens was measured through a dedicated climate system (Climate Sensor in Fig. 5) that used common IoT sensors from Monnit 8 to measure the luminosity, temperature, and humidity. Among the collected pig-related information, the most important ones that are mapped to the NGSI data model used in this study are the Animal ID, the pig location that represents the pen in which the pig is located, the visit time that represents the time at which the pig starts the feeding visit, the duration, that is the duration of the feeding visit in seconds, the weight that is the median weight of the pig measured during the feeding visit in grams, and the feed intake that represents the feed intake of the pig during the feeding visit in grams B. THE NGSI DATA MODEL Fig. 6 shows the entities, their attributes, and their relationships used to represent pig-related information gathered using the Orion Context Broker deployed at the farm. There are six major entities, which are Pig, Pen, Building, Farm, Slaughterhouse, and SlaughterPig. The devices and sensors measure one or more parameters of these entities, and sometimes in groups (which is the case for pigs), and send updates to the Context Broker. The case depicted in Fig. 5 shows only one compartment. Generally, a pig farm contains one or more buildings (pig stables); each building will have multiple compartments, and each compartment will have multiple pens. Furthermore, information from the associated slaughterhouse is represented by two dedicated entities. A JavaScript Object Notation (JSON) example of pig entity data coming from the context broker is presented in appendix A.

C. EPCIS EVENT MODEL
The event model developed in the MEAT TRANSPARENCY AND TRACEABILITY [45] use case of the IoF2020 for the purpose of tracing and tracking of pigs and pork is shown in Fig. 7. An example of an EPCIS event data is shown in Appendix B. The concept of tracking and tracing that led to the event model is as follows. When piglets are born, the ''Birth'' event will be captured. When piglets are moved to (adopted by) another sow, an ''Adoption'' event will be registered. A ''Growth'' event represents any increase or decrease of weights of a pig or a sow in a period of time. A ''Feed intake'' or a ''water intake'' event is captured when there is any pig's food or water consumption. When artificial insemination is done, an ''Insemination'' event is captured. A ''Pen-Up'' event is meant for any addition of animals to a compartment or to a pen. ''Shipping'' and ''Receiving'' events represent any shipping or receiving of animals from or to a new owner. A ''Slaughter'' event is used when an animal is slaughtered at a slaughterhouse. The ''Vet'' event is registered when a veterinary inspects or treats an animal. Any events related to environmental sensor measurements are captured with an ''Environment'' event. In fact, all these events are captured as standard EPCIS object events and differentiated by the specific business step of the event, such as the birth and the adoption. EPCIS events are constructed by assigning the values of the four dimensions of EPCIS events. Assigning a unique ID to each entity represents the ''What'' dimension of the events and establishes the foundation for traceability. GS1 defines multiple identification systems for assigning IDs to objects [26], including Global Trade Item Number (GTIN) and Global Location Number (GLN). GTIN is used to identify a specific class of objects from a specific company. For instance, all pigs from a farm can be assigned to a single GTIN number. A serial number can be added at the end of a GTIN number to create Serialized GTIN (SGTIN), which can be used to identify a specific entity of a product (for instance, a pig) or a specific service. If no individual identification is possible, lot numbers can be added, resulting in a Lot GTIN (LGTIN). GLNs are used to identify locations. Similarly, Serialized GLN (SGLN) can be used to identify specific (sub-) locations within a company. Accordingly, a hierarchical ID system was designed for the use case as shown in Fig. 7 (b). Each pig is assigned an SGTIN, and a group of pigs is assigned an LGTIN. SGLNs are assigned to each pen and compartment. GLN is assigned to the farm.   Fig. 8 shows a sequence diagram from data capture to NGSI up to data accessing through EPCIS by applying the Mediation Gateway. First, the Mediation Gateway subscribes to the context broker to get notifications and new data. After a new update is pushed to the Context Broker by the IoT devices, the Context Broker notifies the mediation gateway with the newly updated data. The Mediation Getaway processes the updated information to check for state change and generate events. If the data processing needs additional entity information, the Mediation Gateway gets the data with a request-response method. It then captures the events to EPCIS for later retrieval by an EPCIS application. Fig. 8 also presents a sample workflow of the Mediation Gateway to show the three types of event generation presented in section III-C via three use cases. In the first case, an update of health information requires additional environment entity information to generate an alert event (a type of Complex Event). The second case shows the workflow when a weight update information is presented. In this case, the change with the previous weight is compared against a threshold value to generate a growth event (a type of Simple event). The last case presented a workflow of generating birth events from birth update information (a type of Simple Translation).

V. DISCUSSION AND EVALUATION A. DISCUSSION AND FUTURE WORK
Due to globalization, the distance that food travels from source (producer) to destination (consumer) has increased. This makes food quality and safety one of the major concerns in the food industry. To ensure the integrity of the food supply chain, all involved parties demand verifiable evidence of the source and destination of food. To tackle these requirements, traceability systems that provide information on the origin, processing, and distribution of foodstuffs are required.
Although the pilot study used in this paper demonstrates the ability to capture information only up to the slaughtering step, full traceability can be achieved when subsequent organizations capture and open their data either via their own EPCIS instances or using the FIWARE context broker. For instance, in Europe, METRO Group is using EPCIS for its ProTrace Application to Track and Trace meat, fish, etc. [11]. GS1 Germany provides the service using its fTrace system developed by a daughter company [49].
Even though Mediation Gateway's current implementation considers only pig farming, it can be easily extended to other domains. Except for the Event Processor module, all the components are generic and can be used to other domains with little or no modifications. Interfaces for the domains specified by FIWARE Smart Data Models are already included. The subscription URL design considers both the version of the FIWARE standard and the various domains. FIWARE provides a framework (FIWARE Catalog) [40] to assemble open-source platform components with other third-party platform components (FIWARE Enabler) to accelerate the development of Smart Solutions. The Gateway has been accepted as one of the FIWARE enabler which helps for the opensource community to extend to different other domains.
The current implementation considers the NGSI-V2 data model instead of the latest version NGSI-LD. During the design and implementation of the FIWARE system for the pig use case, there was no stable version NGSI-LD standard implementation. Considering the minimum difference in the data model, the authors will provide the NGSI-LD version through the FIWARE Enabler open-source project initiative as soon as there is a stable implementation of NGSI-LD.

B. PERFORMANCE EVALUATION
Since the live data coming from the ILVO farm in the use case is small, to evaluate the Mediation Gateway performance, the authors conducted a load testing experiment using VOLUME 9, 2021  nGrinder, 9 a framework for running test scripts across several machines. An experimental setup has been prepared, which contained nGrinder load generator, Mediation Gateway, and EPCIS, as depicted in Fig. 9. The load generator contains a controller, which controls the different agents who are available in the same machine or in a different machine. Each agent can create multiple virtual users (vUsers) that concurrently execute the controller's job to inject load into the system under test. The experimental setup of each system is described in Table 1.
To evaluate the Mediation Gateway under different test loads, the authors set up two agents to create concurrent users starting from 1 up to 3000 in a range of 100. Each concurrent user generated an NGSI based pig model that simulated feed intake, water intake, and weight change. This means each virtual user simulates users running in parallel and pushes NGSI data to the Mediation Gateway. Therefore, for each concurrent data feed, three events will be generated: 9 http://naver.github.io/ngrinder/ a feed-intake event, a water-intake event, and a growth event.
To reveal the Mediation Gateway overhead due to processing and translation, the authors created three scenarios: 1) Processing with Capturing: the Mediation Gateway processes the NGSI data from the load injector and translates it to events, and captures it to EPCIS. 2) Only Processing and Translation: in this scenario, the Mediation Gateway only processes and translates the event without capturing it to EPCIS repository. 3) Only Capturing: the Mediation Gateway only captures events without any processing and translations.
The authors used two metrics to evaluate the performance: transactions per second (TPS) and mean response time (MRT). TPS measures how many transactions can be dealt with in a second, whereas MRT measures how fast each request can be executed. The TPS results for the three scenarios are shown in Fig. 10a. Scenario one and two have an average TPS of 26.09 and 27.26 under the environment described in Table 1. Scenario three, instead, has an average TPS of 46.8. This shows that the Mediation Gateway with processing and capturing can achieve 55% of the TPS compared to the Mediation Gateway with only capturing, which indicates that the Mediation Gateway is feasible for IoT systems. Likewise, scenario one and two have an average MRT of 38421ms and 31120ms, respectively. Scenario three LISTING 2. EPCIS growth event example.
has an average MRT of 2340ms. Fig. 10b shows the MRT for the three scenarios.

VI. CONCLUSION
To facilitate the compatibility of IoT platforms, there are currently different efforts in standardizing IoT data and platforms, resulting in two major standards: the NGSI and EPCIS standards. The two standards differ not only in the data encoding but also in the underlying philosophy of representing IoT data; namely, EPCIS is event-based, and NGSI is entity-based. Entity based models are best to capture snapshot information at a specific time and are preferred by data provides who wants to share real-time entity information. In contrast, the event-based model is best for explicit modeling of system dynamics (entity transformation) and is preferred by data providers interested in entity traceability. This creates fragmentation and makes end-to-end sharing of data burdensome. This work presents an interoperability solution between entity-based information systems (NGSI) and event-based information systems (EPCIS), named a Mediation Gateway, which enhances end to end traceability. It introduces a methodology and implementation of how entity-based models are translated into event-based models.
To prove the concept, the proposed Mediation Gateway is applied to the real-life IoF2020 pig use case. In addition to the real live data from pig farming, a load test evaluation using high-speed multi-user simulation was done to show the performance of the designed interoperability system when the Mediation Gateway is applied.
The Mediation Gateway has been designed to be easily extendable to other domains, and the FIWARE Foundation has accepted it as one of the FIWARE Enablers. Consequently, the authors keep providing continuous support to the open-source community to extend it to other domains. As future work, as soon as the NGSI-LD Orion Context Broker stable version will be released, the proposed Mediation Gateway will be extended and tested to verify the compatibility with the latest NGSI-LD standard version. We are also committed to provide support, to improve and extend to other domains (delivery robots, medical sector, etc.) through the FIWARE enabler open-source initiative.

APPENDIX A FIWARE PIG ENTITY EXAMPLE
See Listing 1.

APPENDIX B EPCIS GROWTH EVENT EXAMPLE
See Listing 2.

ACKNOWLEDGMENT
The ''pig farm management'' use case is a collaboration between ILVO, Links Foundation, Evonik Porphyrio, ZLTO and Vion Food Group. The ''meat transparency and traceability'' use case is a collaboration between Wageningen University and Research, GS1 Germany, Korea Advanced Institute of Science and Technology, and European EPC Competence Center. He is currently working with LINKS, leading the Architectures and Interoperability Solutions Team in the IoT and pervasive technologies research area. He participated in several national research and development projects, including EU funded research and development projects, where he has designed and developed platforms for the easy integration and virtualization of devices and robotics simulation tools. He is the coauthor of several conference papers related to this topic. His main research interest includes the Internet of Things infrastructure and applications. Since April 2015, he has been a member of the XMPP Standard Foundation.
GEORG SCHWERING received the Diploma degree in chemistry from the University of Münster, in 1998, and the Ph.D. degree in physical chemistry from the Max Planck Institute for Solid State Research, in 2003.
From 2005 to 2016, he worked in various divisions of the international wholesaler METRO Group, focusing on the implementation of RFID and the IoT technology, EPCIS-based traceability solutions and cross-partner data exchange, and mobile applications. Since 2017, he has been the Head of Scientific Research Projects with the European EPC Competence Center (EECC) at Neuss and Cologne, Germany. His research interest includes the development of solutions for full traceability of things and services in various industries and the exchange of data using standardized interfaces. He is always on the lookout for new IoT solutions to make things and processes self-managing and self-optimizing.
JARISSA MASELYNE received the Ph.D. degree in bioscience engineering from KU Leuven. Her Ph.D. Topic was automated monitoring of feeding and drinking patterns in growing-finishing pigs: towards a warning system for performance, health and welfare in individual pigs. She is currently working as a Researcher with the Group of Agricultural Engineering, Flanders Research Institute for Agriculture, Fisheries and Food (ILVO), with a main focus on precision pig farming. She is currently the Vice-President of the Precision Livestock Farming Committee, EAAP. She is also an Electromechanical Engineer. She is involved in various European projects, as a WP (co-)lead or task lead, on the topics of the Internet of Things (IOF2020), high performance computing (CYBELE), and renewable energy systems (RES4LIVE) for livestock farming. She is the (co)author of several articles in the field of precision livestock farming.