Ian Thomas

Shinji Kikuchi

Emmanuel Baccelli

Kaspar Schleiser

Joerg Doerr

Andreas Morgenstern

Design and implementation of a platform for hyperconnected cyber physical systems

The Internet of Things (IoT) is an area of growing importance as more and more computing capability becomes embedded into real world objects and environments. But at the same time IoT is just one component of a widespread shift towards a new age of federation, combining with other trends such as cloud computing, blockchain and automation to create a new hyperconnected infrastructure. This infrastructure will emerge from the convergence of traditional, cloud and IoTbased models of computing, creating a more decentralised, secure and democratic computing platform for the future. But while bringing significant benefits, federation also brings significant problems -in particular the complexity of building, integrating and managing systems built using highly distributed and heterogeneous platforms. In this paper we discuss our work on modelling, deployment and management for this new converged computing environment, leveraging previous work on domain languages, cloud computing and the Web of Things to accelerate and democratize the development of real world hyperconnected systems.

I. INTRODUCTION

The Internet of Things (IoT), is an emerging computing paradigm in which a wide range of physical objects -such as machines, vehicles, appliances, wearables etc. -are equipped with sensing, processing and connectivity features. Analyst firm Gartner predicts that the number of deployed IoT devices will grow from 5 Billion in 2015 to 25 Billion in 2020 [START_REF]Gartner Says 4.9 Billion Connected "Things" Will Be in Use in 2015[END_REF], making IoT one of the most important trends in the field of computer science [START_REF] Tan | Future internet: The internet of things[END_REF].

At the same time we anticipate that IoT will combine with the cloud to create a new hyperconnected infrastructure -a distributed computing fabric consisting of multiple cloud platforms and billions of smart devices [START_REF] Biggs | Emerging issues for our hyperconnected world[END_REF] [START_REF] Vermesan | Building the hyperconnected society: Internet of things research and innovation value chains, ecosystems and markets[END_REF]. Today, however, these environments are largely viewed as separate, with distinct technologies, tools and management approaches applied to each. Beyond the collection of device data in the cloud for further analysis there is typically very little functional overlap between the two worlds in today's pioneering deployments, limiting the utility of the whole.

But as we drive towards increasingly distributed infrastructures, today's centralized cloud-based processing models will need to evolve; real world data is simply too massive, complex and time sensitive to always send to the cloud for processing.

Being able to quickly build, test and evolve systems deployed across the full range of cloud and IoT infrastructure will therefore become critical to placing intelligence in the right place and meeting the needs of next generation digital systems. But today's IoT is not well suited to fast iteration and rapid, continual deployment, while the divergence in tools, practices and skills between the cloud and IoT is often a barrier to mainstream adoption. Furthermore current work on 'fog' computing often focuses on relatively powerful innetwork infrastructure or the use of high-capability devices such as the Raspberry Pi, but these approaches cannot reach all the way to the furthest edges of the network where we expect to see huge numbers of very low cost but highly constrained devices deployed over the next few years as IoT penetrates more deeply into the fabric of society.

In this paper, we therefore outline our work to extend the rapid development, deployment and evolution characteristics of the cloud into the most constrained corners of the IoT, enabling fast and iterative development of converged hyperconnected solutions in line with cloud best-practices such as modelling, continuous deployment [START_REF] Miorandi | Internet of things: Vision, applications and research challenges[END_REF], microservices and serverless execution [START_REF] Baccelli | Scripting Over-The-Air: Towards Containers on Low-end Devices in the Internet of Things[END_REF]. In this way our work aims to reduce the significant technical and skills-based barriers to creating hyperconnected systems, unify the tools and practices necessary to deliver them and create a more agile, responsive and configurable IoT -encompassing every kind of node from the most powerful to the most constrained.

II. FROM A PASSIVE TO AN ACTIVE IOT

In previous work we described our vision to enable composite business ecosystems, a new kind of organizational paradigm in which people co-create value by connecting resources [START_REF] Thomas | Composite Business Ecosystems for the Web of Everything: Using Cloud Platforms for Web Convergence[END_REF]. As part of this work we introduced RunMyProcess [10], a platform that simplifies the creation of complex, cloud-based applications. By offering users a way to easily model, integrate and deploy processes in the cloud, RunMyProcess simplifies the deployment and management of business functionality for organizations around the world.

During this previous work we were primarily focused on extending the ability of our platform to easily connect to resources within the Web of Things [START_REF] Thomas | Making it all work together enabling new business models in the web of everything[END_REF] and on enabling the use of IoT-based data within real-time business processes as part of our vision of composition. During real-world testing [START_REF] Thomas | Towards a Human Centric Intelligent Society: Using Cloud and the Web of Everything to Facilitate New Social Infrastructures[END_REF][START_REF]Transforming Financial Services for a hyperconnected world[END_REF], however, we discovered that collecting data was not enough; in fact we found a range of use cases in which we needed to move more of the intelligence out of the cloud and into the nodes themselves. Without this ability we found ourselves unable to deal with issues in real time and often overloaded with the costs of processing worthless data.

In trying to address these issues, however, we quickly ran into several problems due to the differing lifecycles of cloud and IoT based systems. Changes to the overall system that seemed trivial could be addressed on the cloud side in minutes but would often cause significant delays as we customized firmware on the device side. Rolling out updates would be instant for the cloud elements but be far more complex for the device side. Finding skills for the IoT aspects of the development was a challenge, with deep expertise in hardware and low level programming languages a pre-requisite for customization. And the fragmentation of the environmentwith different tools, practices and approaches -made it very difficult to run a combined lifecycle with common testing and deployment; often we could only test after a long and painful update on the IoT side.

For these reasons we decided to extend our vision of composition out of the cloud and into the IoT, aiming to find a way of bringing the same benefits of fast delivery, continuous deployment and simple management into the whole hyperconnected environment (Figure 1).

III. CREATING A CONVERGED PLATFORM FOR HYPERCONNECTED SYSTEMS

In considering the goals for our extended platform research we therefore set ourselves four major goals: Given that accessibility of skills is a major barrier to the growth of the IoT, preserving the simplicity and accessibility of an established, model-based approach was a key goal in extending the scope of our platform to encompass the direct deployment of IoT device behavior.

2) Flexible deployment: Logic should be able to be deployed seamlessly to both the cloud and the IoT. We believe that we must simplify users' view of the world, enabling them to focus on the business logic they require without worrying about the wide range of nodes, topologies, protocols and other technical challenges that exist at the intersection of cloud and IoT.

3) Easy integration: When modelling functionality users should be able to easily connect resources whether they physically exist within the cloud or the IoT. We want to reduce unnecessary friction between cloud and IoT systems in order to simplify development of complex distributed systems and encourage innovation.

4) Power optimized:

The approach should not require expensive firmware updates and distribution. Working with cheap, low cost devices means limiting the power, energy and bandwidth burdens our approach places onto the IoT hardware.

IV. DESIGNING A CONVERGED ENVIRONMENT

To map the capabilities we needed to generate IoT solutions, we began by building a conceptual architecture of the environment we wished to realize. This led to our intended functional architecture, as described in Figure 2: To meet our goals we had some particular requirements based on our prior experiences. Firstly we wanted to enable less skilled people to model the device functionality they needed and deploy it easily and immediately alongside the other cloud-based components that made up their overall solution. These components were assigned to our cloud platform layer. At the opposite end -to enable this -we also wanted to eliminate the painful customization of firmware by relying on a device 'operating system' that could hide the differences in a broad range of standard devices and could be extended to offer an execution container for process definitions. These components were assigned to our device layer. But to make the two layers work together we needed to create a shared meta-model.

One of the most important elements of this architecture was therefore the domain meta-model of concepts needed to satisfy our implementation goals (Fig 3 .).

By using a range of real world use cases provided by enterprises -spanning retail, utilities, facilities management and manufacturing -we were able to identify the core concepts that needed to be expressed within our models and supported by our execution environment -from steps within a process through to timers, sensor thresholds and external communication. In addition we used IPSO smart object definitions to capture the IoT specific information about the capabilities of each object. By building up and using this meta-model we were able to visualize requirements across the whole architecture, from the elements that needed to be modelled within our cloud environment to the capabilities our device runtime container needed to interpret and execute the modelled functionality (Figure 4).

V. PLATFORM IMPLEMENTATION

Together with our research partners we implemented the capabilities outlined in Figure 2, creating an environment in which is it possible to model and deploy functionality to the IoT in a simple, fast and iterative way (Figure 5) The implemented platform consists of three main elements -the cloud modelling and execution environment, the communication model and the open IoT platform. We will describe each in turn.

A. Cloud modelling and execution

The cloud modelling and execution environment is the main working environment for people using the platform. It provides the modelling, registry, deployment and management capabilities necessary for the creation of converged cloud-IoT solutions.

1) Cloud based modelling: Using RunMyProcess we built an IoT modelling canvas which enables users to graphically model and deploy functionality to be executed in the smart IoT node. It enables users to browse the available device types in the registry together with the configurations and available resources for each. We considered a range of different modelling techniques for building this functionality, in particular state machines, but after testing different approaches we concluded that BPMN 2.0 models provided the best match between the concepts we had dicovered in the meta-model and our ease of use requirements. In particular we appreciated the fact that (i) BPMN 2.0 is a language which reflects the way that non-IT users are accustomed to think and that (ii) it uses an XML-notation which was verbose enough to facilitate transformation into other assets such as code, increasing our architectural options. We also noted studies which suggested that BPMN is a more IoT-aware modelling approach when compared with alternatives such as eEPC (extended EPC) or UML activity diagrams [START_REF] Meyer | Towards modeling real-world aware business processes[END_REF]. A screenshot of the process modelled for the example scenario in section VI is presented in Figure 6. 2) Open LWM2M registry: In order to keep track of the devices that we wish to manage and update we needed to integrate a repository into our existing cloud environment. Unlike with cloud deployment there is no central, homogenous runtime for the functionality being developed, so we need to understand the capabilities of each device and be able to choose which ones should receive any new behaviour. For IoT device management we chose to use the OMA Lighweight M2M standard [START_REF] Alliance | Lightweight machine to machine technical specification[END_REF], giving us a standards based model for interacting with devices. To implement this component we integrated Eclipse Leshan, an open source implementation of LWM2M written in Java [START_REF] Leshan | [END_REF]. It relies on Californium to provide CoAP and DTLS support and provides a simple web interface for viewing and interacting with the list of connected LWM2M clients. By integrating Leshan into our environment we have enabled people to choose the device type they wish to target new functionality towards.

3) Javascript generation and deployment: Once modelling is complete we need to deploy the functionality to the underlying devices. We considered a range of approaches for this but finally decided to transform the BPMN model into JavaScript, due to its widespread use and the availability of interpreters on a large number of device platforms. In order to achieve this the cloud environment dispatches the BPMN model to a domain specific language (DSL) server. Using the concepts from the meta-model the DSL server is able to transform the model into Javascript compatible with the device execution engine and its enabling APIs. We considered several language workbenches for the creation of the DSL server, including Xtext, MPS, spoofax, Rascal and ANTLRan excellent comparison of the different features of these popular DSL workbenches can be found in [START_REF] Erdweg | Evaluating and comparing language workbenches: Existing results and benchmarks for the future[END_REF] -but finally decided to adopt the eclipse-based Xtext. We made this decision due to its wide use across industry, ease of access through open source and the fact that it can be used to compile to any target language.

Once the BPMN model is transformed into Javascript it is then deployed to the chosen devices using CoAP.

B. Cloud-IoT communication

Over the last few years there has been significant and growing interest in the use of internet protocols to bridge the traditionally separate worlds of the Web and embedded devices in order to create an Internet of Things. One benefit of such an approach is the ability to enhance the discrete functionality of individual devices with additional logic in the cloud, using the speed and scale of cloud development to build more intelligent systems. While it has been demonstrated that existing Web architectures and protocols can successfully be used for the integration of constrained devices [START_REF] Guinard | A Resource Oriented Architecture for the Web of Things[END_REF], it is unlikely that such an approach will be suitable for the types of limited capability devices we intended to support in this project.

For this reason we adopted the Constrained Application Protocol (CoAP) [START_REF] Shelby | RFC 7252: Constrained Application Protocol (CoAP)[END_REF]. CoAP attempts to create a balance between consistency on the one hand and recognition of the limited power, reliability and bandwidth available to constrained devices on the other. When combined with the wider efforts of the IETF in creating 6LoWPAN [START_REF] Kushalnagar | IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement & Goals, IETF RFC 4919[END_REF] we can clearly see the foundations emerging for a Web of Things [START_REF] Zeng | The Web of Things: A Survey[END_REF]. Support for CoAP within RunMyProcess was the subject of previous work [START_REF] Thomas | Making it all work together enabling new business models in the web of everything[END_REF].

In particular while CoAP is not a compression of HTTP it does offer a consistent interaction model along with best practices for mapping [START_REF] Castellani | Best Practices for HTTP-CoAP Mapping Implementation, Internet Draft[END_REF]. Using CoAP, individual resources continue to be identified and addressed via Universal Resource Identifiers (URIs), represented using arbitrary formats (such as JSON or XML) and manipulated using the same methods as HTTP. This use of a familiar approach will reduce the complexity of managing, integrating and updating distributed devices from our cloud platform.

C. Open IoT platform

As already discussed the use of an IoT "operating system" was a key enabler to our overall requirements, shielding developers from the complexities and cost of low level development. A number of IoT operating systems are available for the type of hardware and scenarios we wanted to enable [START_REF] Hahm | Operating systems for low-end devices in the internet of things: A survey[END_REF]. In this project we chose to use RIOT [START_REF] Baccelli | RIOT OS: Towards an OS for the Internet of Things[END_REF][9] as the basic layer of our IoT device platform, an open source operating system with a low memory footprint, high modularity, good interoperability and support for a wide variety of low-end IoT devices.

In order to meet the goals of our project, however, we needed to add significant new functionality to the RIOT environment, including registration, deployment and execution support for our modelled code.

1) Device Registration: As discussed IoT device registration is implemented using Eclipse Leshan, which provides a LWM2M server implementation written in Java [START_REF] Leshan | [END_REF]. To facilitate the cloud to device interactions, we have implemented a minimal LWM2M client within the RIOT environment to register with the server. To expedite our research, the bootstrap process uses simple pre-shared keys. As an example of the registration data exchanged at bootstrap, the LWM2M client in RIOT registers the resources < 3/0 >, < 9/0 >, < 3303/0 > and < 3315/0 > for the example scenario discussed in section VI, which map respectively to the IoT device, the JavaScript container, the light sensor and the sound-level sensor, as per the OMA standard [START_REF] Rao | Implementing LWM2M in constrained IoT devices[END_REF].

2) Javascript code deployment: The code deployment component receives Javascript files and safely installs them into the memory of the device. Deployment messages are sent using CoAP. This approach is used as an alternative to the distribution of binaries, allowing small scripts to be dynamically updated and executed. This is an attractive approach as a result of the emergence of small footprint interpreters such as MicroPython [START_REF]MicroPython Compiler[END_REF] and JerryScript [START_REF]JerryScript: JavaScript engine for the Internet of Things[END_REF]. In this project, we have built upon a small footprint interpreter (JerryScript, as described below), and dynamically load scripts to roll out and update business logic on low-end IoT devices.

3) Javascript code execution: In order to support the execution of the modelled processes, the RIOT OS has been extended with a framework that interfaces between the Javascript logic and the underlying OS. This isolates the business logic from the underlying hardware and low level interfaces and provides a local execution environment for the generated Javascript. This environment enables e.g.:

•

interaction with sensors and actuators; • receipt of reliable, pre-processed data and events extracted from sensors, and • remote interaction with the cloud or other devices in order to exhange information and trigger wider application components.

For the script engine, we chose to create a RIOT package for JerryScript [START_REF]JerryScript RIOT Package[END_REF], a lightweight JavaScript interpreter, and combined it with our new framework. This framework maps the low level APIs offered by RIOT -e.g. timers, sensor interactions, event callbacks etc -into more developerfriendly Javascript. Examples of the resulting RIOT JavaScript APIs are shown in Listing 1.

VI. TESTING

In order to test our work we chose a facilities management use case from the list of scenarios we used as input for our analysis work. This scenario is based on building security management and deals with intrusion detection and resolution. It uses an on-device process to detect and process a combination of light and sound information before making a local decision whether to trigger the attached alarm and notify a security guard via a cloud-based mobile notification (Figure 7). Note that we chose this use-case only for practical, proofof-concept purposes. The approach we present is generic and can easily be applied to a wide variety of other IoT use cases.

A. Executing the scenario

During the execution of the scenario, the IoT device monitors light levels looking for anomalies, with raised light levels set as the 'triggering event' within the process model. At deployment time a threshold event is created within the operating system by the Javascript. If an anomaly is detected then an event is sent from the operating system to the Javascript to trigger the rest of the code representing the modelled process (as shown in Figure 8). Once triggered, the code first listens for sound using the attached sensor in order to attempt to confirm that an intrusion is likely and reduce false alarms. An important point to note is that the implementation of the Javascript APIs used to interface with the underlying operating system pre-process the returned data to minimize noise and anomalies, reducing the need to deal with potential hardware issues within the business logic.

If sound is also detected than the alarm is triggered, a message is sent via CoAP to the cloud in order to trigger the security process and the device process enters a wait state.

On receiving the CoAP message the cloud platform starts a second process to manage attendance by the security guard. This process extracts the necessary data about location and issue and sends a notification via a mobile application implemented with RunMyProcess to alert the security guard. Once accepted the security guard can choose to cancel the alarm from their mobile device (see Figure 9). Once cancelled a message is sent back to the cloud platform, which in turn sends a CoAP message to the device in order to instruct it to switch off the alarm. On receipt of the event the device switches off the alarm, completes the process and returns to monitoring mode.

An overview of the end-to-end components involved in this process can be seen in Figure 10.

Listing 2 illustrates the JavaScript implementation of the process model shown in Figure 8, demonstrating what is deployed to the device. As you will see this Javascript is able to interact with the underlying sensors, actuators and networking components in order to implement the behavior necessary to support the desired scenario.

B. Hardware and connectivity

As many of our goals relate to the use of low power, low capability hardware we wanted to ensure that our approach worked for simple devices. In this section we will briefly outline the hardware and connectivity set up used for the IoT aspects of the project. 1) IoT hardware: In order to meet the requirements of the implemented scenario we produced a low-end IoT device. This device was based on commercially available equipment from Microchip, the SAMR21-xpro [START_REF]Microchip Atmel ATSAMR21-xpro Board[END_REF]. The SMAR21 features a 32-bit micro-controller, 32kBytes of RAM and 256 kBytes of Flash memory, together with an IEEE 802.15.4 radio transceiver. Note that the SAMR21 has no memory protection unit (MPU) in hardware. We extended the SAMR21 with a custom break-out board shown in Figure 11, connecting a light sensor, sound level sensor and revolving light via GPIO.

2) Connectivity: The low-end IoT device was connected the to the Internet via a cheap RaspberryPi with a IEEE 802.15.4 radio module, configured in a standard fashion to act as a border router between plain IPv6 and the LoWPAN [START_REF] Kushalnagar | Ipv6 over low-power wireless personal area networks (6lowpans): overview, assump-tions, problem statement, and goals[END_REF]. The setup is shown in Figure 12.

VII. EVALUATION

At the outset of our project we identified four major goals, simplified development, flexible deployment, easy integration and power optimization. In this section we will briefly review our work in the context of these goals.

A. Simplified development

Our goal here was twofold -to enable non-specialised IoT developers to build IoT application and to enable a faster and more iterative approach to IoT development.

It is outside the scope of this paper to consider whether BPMN is a simple approach in general, but on the assumption that it provides a non-IoT specific way to model business functionality we believe this criteria has been met. From informal testing with colleagues and customers with no specific IoT development experience or skills we have observed that the extended cloud modeling environment enables non-specialized developers to build and deploy simple IoT applications. By using the adapted BPMN modelling language in combination with drag and drop, such users can graphically design the business logic they wish to be executed on the IoT devices.

Equally importantly the deployment of this functionality now happens at the click of a button, enabling a much more iterative cycle of modelling, deployment and testing. In fact we observed a side effect of this process during the implementation of our own test scenario. Because deployment can now be a continuous process rather than a single event we were able to quickly deploy the solution and tune thresholds and other parameters based on observation in situ rather than estimations. We believe that this experience could point to a significant additional benefit of our approach, enabling the faster, cheaper and lower risk deployment of IoT solutions due to the ease of adapting their behavior post-implementation.

B. Flexible deployment

Our extended cloud development environment offers the opportunity to model both cloud and IoT processes within the same environment and using the same concepts and models. Today the developer has to choose from the outset whether they wish the process to be targeted at the cloud or the IoT, since there are some additional concepts and deployment steps necessary for the IoT. As a result while we have succeeded in our main goal of enabling the deployment of processes to the cloud and the IoT as part of the same project/solution within the development environment, it is currently not possible to move such modelled processes between environments as a further optimization. This will be the subject of future research.

C. Easy integration

As demonstrated in our test scenario, processes within the cloud and IoT are able to easily inter-operate at runtime using CoAP. This means that it is simple to create 'hyperconnected' solutions which consist of different components, deployed in different environments, but which are still able to form part of the same over-arching solution through integration. Equally importantly, from a development time perspective the inclusion of a basic device registry makes it easy to discover, introspect and connect devices and their behavior within process flows. This is an equally important perspective in terms of integration. Today much of the work to do this is still manual, e.g. in terms of viewing and copying over information from the registry into the process flow. A topic of future research will therefore be the automation of this kind of activity to enhance developer productivity and reduce risk of errors.

D. Power optimized

In considering the viability of our approach from a resource perspective we have to look at two perspectives: (i) the memory overhead of running the Javascript engine vs directly implementing functionality in C and (ii) the comparative overhead of updating scripts vs firmware updates.

In the first case, we estimate that the total overhead of running the Javascript engine based on our analysis is ~12k of RAM and ~96k of flash memory. While this may look like an overhead vs a native C implementation, the efficiency of the RIOT OS means that it would rarely take the overall capacity requirements outside the scope of the majority of standard offthe-shelf low power devices (e.g. 32k of RAM and 256K of flash memory). In fact our analysis suggests that our solution could be readily compiled and run on more than 84 different types of IoT devices, corresponding to more than 80% of all the IoT hardware supported by RIOT today.

In the second case, the number of bytes transmitted overthe-air to update the functionality of the device for our Security Scenario is 1kB (the size of the script shown in Listing 2). This script is actually relatively complex with multiple accesses of sensors and actuators, calculations and external communications. Compared to this, a full firmware update would require the transmission of an entire image, which in the case of RIOT would be ~60kB. This is a significant penalty in comparison and would represent a challenge to the kind of iterative processes we have outlined. We acknowledge that partial firmware updates could reduce this overhead but believe that the installation process would continue to be more complex and incur a greater overhead.

While our approach therefore introduces some overhead at the outset we believe it could significantly reduce cumulative overheads across the entire lifecycle of a device, extending its life as well as delivering the already outlined benefits of agility and convergence.

VIII. RELATED WORK

Building today's IoT solutions is a challenging task because developers need to have extensive technical knowledge spanning embedded systems, networking and protocols. The resulting low level development and technical work not only makes the creation of IoT applications slow, error-prone and cumbersome but also significantly restricts the pool of people who can engage with IoT for solving realworld problems. As a result of these challenges, many researchers have been considering how to accelerate the creation of IoT applications. As we can see by reviewing the landscape, however, the primary approach taken to date has focused on the creation of cloud-based functionality -as opposed to IoT-based -limiting their utility in situations where a more federated approach is required.

In our previous research we proposed a cloud-based architecture for composing value from the IoT [START_REF] Thomas | Composite business ecosystems for the web of everything: using cloud platforms for web convergence[END_REF]. In this model our cloud platform made it possible to easily create systems that orchestrated IoT data outputs with other kinds of web and on-premise resources. It was the limitations of this approach during real-world testing, however, that led to the research outlined in this paper.

In [START_REF] Fatmasari Rahman | Understanding IoT Systems: A Life Cycle Approach[END_REF], life cycles for IoT devices, services and applications are discussed. It gives hence an academic framework under which different aspect of IoT development can be discussed but gives no practical implementation.

Spacebrew [START_REF]Spacebrew[END_REF] is an open software toolkit which enables outputs and inputs to be connected, creating an implicit 'flow'. However, it is based on a publisher/subscriber which may be challenging for non-professional software developers. Equally importantly Spacebrew cannot run functionality directly on devices, relying instead on intermediate computers that share data from the devices to which they are connected (e.g. Arduino).

Paraimpu [START_REF]Paraimpu[END_REF] [25] is another software system proposed for simplifying the creation of systems which connect physical objects, APIs and services, composing them together to create new applications. Again, however, the focus here is on connecting data from existing objects rather than adapting their behaviour through the deployment of business logic.

Actinium [START_REF] Kovatsch | Actinium: A restful runtime container for scriptable internet of things applications[END_REF] presents a web-like scripting approach for composing low-end devices, providing a RESTful, cloudbased run-time container with dynamic installation, update, and removal of scripts. While the goal of Actinium is also to simplify the development of converged systems, its approach focused on cloud-based scripts which do not change the behaviour of the underlying devices themselves. [START_REF] Martins | Modelling IoT behaviour within BPMN Business Processes[END_REF] Discusses an approach similar to ours that uses the BPMN to model behavior of wireless sensor networks. They compile the BPMN edge device behavior to the callas language and execute it on the callas virtual machine. In contrast to that, we compile the BPMN process to javascript. According to [START_REF] Mendes | A Modular Virtual Machine for the Callas Programming Language for Wireless Sensor Networks[END_REF], the callas virtual machine is only available for SunSpot devices whereas we expect that javascript interpreters will be available for a large number of different devices.

The WoTkit Processor, bundled with the WoTkit platform [START_REF] Blackstock | Iot mashups with the wotkit[END_REF] [START_REF] Blackstock | Wotkit: a lightweight toolkit for the web of things[END_REF], is another cloud-based tool for building applications that use IoT resources. As with the other options, however, it focuses on aggregating sensor data within the cloud before building cloud-based applications that leverage its value.

Finally NodeRed [START_REF] Nodered | [END_REF] is a web-based tool for creating flows that connect hardware devices, APIs and cloud services, with modelling offered via a browser-based flow editor. From the perspective of our research, NodeRED is the closest prior work to our proposed solution, offering the ability to model and deploy functionality to the edge of the network. Node RED still requires that flows are deployed to either the cloud or to general purpose computing devices with a traditional operating system (such as the Raspberry Pi [START_REF]Raspberry Pi -Teach, Learn, and Make with Raspberry Pi[END_REF]). For this reason NodeRED did not satisfy our requirement for behaviour deployment to constrained devices. Furthermore, while partially addressing the issues of development simplification through a flow editor, NodeRED did not address the wider issues of end-to-end process integration and device lifecycle management that are a core part of our research.

Several other platforms [START_REF] Kovatsch | Californium: Scalable cloud services for the internet of things with coap[END_REF] [19] [33] [27] have also been proposed to ease the development of IoT applications but in all cases they do not cover the major features we propose, including integration of device registry, workflow editing, wireless deployment and end-to-end orchestration.

Besides these technical papers that discuss the creation of solutions for the IoT-domain, there are also a couple of papers that discuss new and emerging business models related to IoT [START_REF] Metallo | Understanding business model in the Internet of Things industry[END_REF][START_REF] Krotov | The Internet of Things and new business opportunities[END_REF][START_REF] Ju | Prototyping Business Models for IoT Service[END_REF]. We have shortly touched these topic at the beginning of our paper but refer the interested reader to the mentioned papers that discuss these topics in more detail.

IX. CONCLUSION

In this paper, we have examined one possible route to simplifying the development of new hyperconnected systems that span both cloud and IoT infrastructures. To date the ease of development of IoT applications has lagged the cloud significantly, lacking easy support for established concepts such as modelling, agile delivery and continuous deployment, concepts which have transformed the development of more mainstream software.

Figure 1 -

 1 Figure 1-Bringing the best of web and cloud to the IoT via fast cycles and efficient deployment

Figure 2 -

 2 Figure 2 -Top level conceptual architecture

Figure 4 -

 4 Figure 4 -Transforming inputs into components via a meta-model

Figure 5 -

 5 Figure 5 -End to end modelling and deployment for IoT

Figure 3 -Figure 6 -

 36 Figure 3 -Meta-model of solution space

Figure 7 -

 7 Figure 7 -Test scenario

Figure 8 -

 8 Figure 8 -Modelled security process (top layer is device process)

Figure 9 -

 9 Figure 9 -Option to cancel the alarm on the mobile device

Figure 11 -Figure 12 -

 1112 Figure 11 -IoT test hardware

1 )

 1 Simplified development: Non-specialised developers should be able to build, deploy and test IoT applications.

The work described in this paper aimed to address this gap by building development, deployment and management support for IoT devices based on established cloud practices.

To this purpose we have created a cloud-IoT platform composed of a set of components: a generic IoT device operating system (RIOT), an accompanying 'psuedocontainer' for the execution of business logic on low-end devices and a cloud-based development tool for rapid business-logic modelling and deployment, We have presented our test implementation in order to illustrate the workings of this platform and to help examine the ways in which our work can enable our core aims of simplified development, flexible deployment, easy integration and power optimization.


Leo A Siiman

Mario Mäeots

ASSESSING STUDENTS' DIGITAL LITERACY WITH INTERACTIVE COMPUTER-BASED TASKS CREATED IN GOOGLE APPS SCRIPT

Keywords: Assessment, Digital literacy, Digital competence, ICT skills, DigComp framework

This paper presents the development and testing of two interactive computer-based tasks for assessing aspects of students' digital literacy. The tasks were created using Google Apps Script to allow students to work with authentic digital productivity tools. Results from 156 university students indicate that the task requiring analysis of data in a spreadsheet application was significantly more difficult than the task requiring information literacy to make edits in a word processor application. These types of tasks offer more authentic ways for students to engage with digital technology during the assessment of their digital literacy. This study highlights the potential of Google Apps Scripts for developing and delivering tasks in performance-based assessments of students' digital literacy.

INTRODUCTION

The importance of digital literacy has increased considerably in recent years. Personal smart devices not only provide access to a vast amount of information via the internet, but are increasingly able to interact with electronic devices at home and in other daily life situations. The changes brought by modern digital technology make it essential to prepare all people to best take advantage of these new possibilities. Educational systems have a role to play in shaping the digital literacy of young people. However, in order to monitor and support the development of students' digital literacy, a way of assessing digital literacy is needed. Performance-based assessments offer a more authentic approach to measuring digital literacy because they compel students to demonstrate their competence and can thereby ensure a more a reliable and valid measurement.

The concept of digital literacy is much more than simply learning how to use a digital device or how to perform online searches. Digital literacy is a set of skills (how to do something with digital technology), knowledge (what is it possible to do with digital technology), and attitudes (is a person ready and confident to use digital technology). It is the ability to use digital technologies for searching, assessing, creating, managing and communicating information broadly [START_REF] Al-Qallaf | Digital literacy and digital content supports learning: The impact of blogs on teaching English as a foreign language[END_REF][START_REF] Janssen | Experts' views on digital competence: Commonalities and differences[END_REF][START_REF] Hatlevik | Predictors of digital competence in 7th grade: a multilevel analysis[END_REF]. Thus, digital literacy is concerned with different practices. As such, there exist many terms used by researchers that overlap to various degrees with the concept of digital literacy: e.g., digital competence [START_REF] Ferrari | DIGCOMP: A framework for developing and understanding digital competence in Europe[END_REF], information and communication technology (ICT) skills [START_REF] Kaarakainen | Performance-based testing for ICT skills assessing: a case study of students and teachers' ICT skills in Finnish schools[END_REF], computer and information literacy [START_REF] Fraillon | International computer and information literacy study: Assessment framework[END_REF], etc. It is thus important to recognize that examples of assessment tasks for measuring aspects of digital literacy can come from prior research that labelled the concept of digital literacy differently.

Siddiq et al. [START_REF] Siddiq | Taking a future perspective by learning from the past-A systematic review of assessment instruments that aim to measure primary and secondary school students' ICT literacy[END_REF] conducted a systematic review to find instruments that assessed the ICT literacy of primary and secondary school students. They found that most tests were comprised of multiple-choice constrained response questions. Only 3 tests out of the 38 reviewed reported applying a performancebased approach, i.e. a test design which mimicked an authentic situation to a large degree. Nine tests reported using tasks with interactive stimulus and response formats. The authors concluded that there is a demand for assessment instruments to measure what is considered to be authentic ways of interacting with technology. Furthermore, [START_REF] Siddiq | Taking a future perspective by learning from the past-A systematic review of assessment instruments that aim to measure primary and secondary school students' ICT literacy[END_REF] found that a large majority of tests focused mainly on assessing students' digital information search, retrieval, evaluation and technical skills. Similarly, Siiman et al. [START_REF] Siiman | A Review of Interactive Computer-Based Tasks in Large-Scale Studies: Can They Guide the Development of an Instrument to Assess Students' Digital Competence?[END_REF] examined interactive computer-based tasks from several large-scale educational assessments related to assessing digital literacy and found that these tasks do not measure many aspects of digital competence that are described, for example, in the DigComp framework [START_REF] Ferrari | DIGCOMP: A framework for developing and understanding digital competence in Europe[END_REF][START_REF] Vuorikari | DigComp 2.0: The digital competence framework for citizens[END_REF].

In general, performance-based assessments are preferred over self-report measures, as the latter do not indicate how competent a student is according to standardized metrics [START_REF] Aesaert | Direct measures of digital information processing and communication skills in primary education: Using item response theory for the development and validation of an ICT competence scale[END_REF]. Therefore, in order to better assess the construct of digital literacy, it is preferable to create practical tasks in which the respondent can demonstrate his or her knowledge and skills through performance on a task, rather than selecting an answer from a prescribed set of alternatives.

The use of simulated environments to provide a more authentic test environment when assessing aspects of digital literacy has often required developers to create custom-made simulated environments [START_REF] Fraillon | International computer and information literacy study: Assessment framework[END_REF][START_REF] Valiente | PISA 2009 Results: Students On Line Digital Technologies and Performance[END_REF][START_REF] Goodman | Literacy, Numeracy, and Problem Solving in Technology-Rich Environments among US Adults: Results from the Program for the International Assessment of Adult Competencies 2012. First Look[END_REF][START_REF] Claro | Assessment of 21st century ICT skills in Chile: Test design and results from high school level students[END_REF]. Such an approach entails substantial technical effort that diverts resources from the main goal of designing and validating tasks to measure aspects of digital literacy. Researchers would benefit from using an existing technical environment to assess digital literacy and which can be adapted to a variety of contexts. In this paper we propose that Google Apps Scripts be used to create testing environments which can help scholars better measure aspects of digital literacy. We demonstrate this proposed solution by developing two interactive tasks with Google Apps Script and test them with university students via the Moodle learning management system.

METHODOLOGY

Participants

Participants for this study were first-year BA and MA university students studying in the humanities or teacher education curricula at the University of Tartu. Complete data from a total of 156 students was obtained. There were 15 students who were provided with English language versions of the tasks. The remaining students worked on Estonian language versions of the tasks.

Materials

Two interactive computer-based tasks for assessing aspects of students' digital literacy were developed for this study. In order to allow students to engage with authentic digital productivity tools, Google Apps Script was used for task development. This approach allows interaction with the popular web-based productivity tools offered by Google, such as Google Docs, Google Sheets and Google Slides. It also allows for creation of a new document, spreadsheet or presentation each time a student opens a task, and conveniently stores the file in a Google Drive folder that can be shared with multiple people.

Automated scoring was also achieved using Google Apps Script. This was implemented using a "Generate Code" button in the task. Both tasks instructed students to make changes in a productivity app and when finished press the Generate Code button. The result of pressing the button is an alphanumeric code that the students were instructed to copy into an input box. By pressing the Generate Code button, a student initiates execution of a Google Apps Script program that analyzes whether the changes made are correct, and generates output which for students appears cryptic, but for the task creators is informative for scoring purposes. For example, when a task is first started a message appears saying: Your code is currently 0.

After pressing the Generate Button the result might be:

Your code is now 20190201152754830-55. This new code is prefixed with a timestamp which can be used to find the relevant file in the shared Google Drive folder and is post fixed with a numeric value (in this case 55) that corresponds to a certain score for this task.

Task 1

The first task we developed was intended to elicit competences related to information and data literacy. It required students to search the internet for information about a common style for citing sources in scholarly works and correctly apply it to example text in a Google Doc editor. The instructions for Task 1 read as follows:

In her research paper, a student wants to refer to the book "Research Design: Qualitative, Quantitative and Mixed Methods Approaches "by John W. Creswell. The research paper guidelines specify that APA (American Psychological Association) style must be used for reference. Please correct the student's reference below so that it corresponds to APA style. After you have correctly formatted the reference, please click the "Generate code" button and write the code in the text box below. There are three main changes that need to be performed to successfully complete this task: 1) add the authors' initials after his last name, 2) move the year position to immediately after the author name, and 3) place the book title in italics font. The Estonian version of the task required students to make these same changes to the reference: Õunapuu. Kvalitatiivne ja kvantitatiivne uurimisviis sotsiaalteadustes. Tartu: Tartu Ülikool 2014. which when formatted correctly in APA style looks like: Õunapuu, L. (2014). Kvalitatiivne ja kvantitatiivne uurimisviis sotsiaalteadustes. Tartu: Tartu Ülikool.

The scoring of Task 1 was performed automatically by the Google Apps Script and assigned one point for each change that was correctly made.

Task 2

The second task we developed was aimed at digital content creation related to making basic statistical calculations of data and presenting the data visually in a chart. It required students to make calculations by using functions in Google Sheets such as "=STDEV(A2:A25)". The instructions for Task 2 read as follows:

Students' test scores were collected for a study. You can see them below in the "Test scores" column of the spreadsheet. Please use the spreadsheet to calculate the number of students who participated in the test, the average score of the test results, and the standard deviation. Insert them in "Table 1". Then, please create a histogram under "Figure 1" representing the distribution of the test results. Name the horizontal axis "Scores" and the vertical axis "Frequency". Change the value of the horizontal interval so that the value is 5. After you have finished making the table and the histogram, click the "Generate code" button and write the code in the text box below.

Figure 2 shows a screenshot of how the interactive area of task 2 appeared to students. The scoring of Task 2 was performed automatically by the Google Apps Script and calculated one point if all the items in the table (i.e., number of students, average score, standard deviation of scores) were correctly filled in and two points if both the table and the figure were correctly completed. Figure 3 shows a screenshot image of the task successfully completed.

Procedure

Participants were informed by their instructor to take a test in their Moodle course. The test was applied in two different e-courses. Students who studied in the teacher education curriculum took it in a course about digital literacy, whereas students in the humanities curriculum took the test during an introductory course to humanities. The tasks were available in their respective Moodle course pages and one week was allocated for them to be completed. Students could complete the tasks at home at their own leisure. The directions for completing the tasks asked students to work on them individually and not ask any other person for assistance. However, they were allowed to search the internet for any information that could be useful in completing the tasks. The results of the tasks were saved in Moodle and the data accessible to the authors for analysis.

RESULTS AND DISCUSSION

The results of the tasks are presented in Table 1 and show the distribution of points for each task. The results show that while 60% of students received full or partial credit on Task 1, only 49% did so on Task 2. This suggests that analyzing data in a spreadsheet application and creating a graphic visualization is more difficult than searching for information in order to make edits in a word processor application. More generally, it suggests a difference in students' digital literacy between information related tasks and digital content related tasks. A Pearson chi-square test revealed no association between the two tasks (Χ 2 (2)> = 2.848, p = 0.828). Differences between information and digital content creation activities by young people was observed by Siiman et al. [START_REF] Siiman | A Review of Interactive Computer-Based Tasks in Large-Scale Studies: Can They Guide the Development of an Instrument to Assess Students' Digital Competence?[END_REF], who conducted a survey of smart device use and found that student use of these devices, whether at school or outside of school, for content creation was considerably less that their use for information related activities. Van den Beemt et al. [START_REF] Van Den Beemt | The use of interactive media among today's youth: Results of a survey[END_REF] investigated the use of interactive media with a range of participant ages and used cluster analysis to distinguish between four groups, which they labeled as 'Traditionalists', 'Gamers', 'Networkers', and 'Producers'. Traditionalists made use of only the basic functions of interactive media (e.g., browsing activities like searching, watching videos or reading news sites) whereas Producers were active content creators. The number of Producers in their study was the least among all four groups and half the number of Traditionalists. Claro et al. [START_REF] Claro | Assessment of 21st century ICT skills in Chile: Test design and results from high school level students[END_REF] measured the ICT skills of students using a performance-based assessment in a virtual environment. Their results showed that most students were able to solve tasks related to the use of information as consumers, but had difficulties when using information as producers.

Overall, our results are consistent with prior findings that show that students are much better at information related tasks compared to content creation tasks. It is thus reasonable to suggest that educational policymakers and educators consider ways of offering students more opportunities for digital content creation activities during learning.

CONCLUSIONS

Changes in society have led to the expansion of new practices through which new literacies emerge. Sometimes the change is rather quick and there is not enough time to develop a common and evidence-based understanding of the new literacy. The same might happen with digital literacy. Although research strives to understand what digital literacy is and how to assess it, there is still a long way to go and we do not know whether we can solve it before a new literacy emerges and replaces digital literacy. Although the construct of digital literacy may be labeled differently in the future, it is important that students are provided with opportunities to improve their digital literacy in areas where they may be weakest.

In this paper, we introduced an example of interactive test items embedded in the Google productivity environment which is but a small step towards adding knowledge to the research field of assessing digital literacy. More studies with a wider range of interactive test items are needed before we can begin to accurately characterize the various aspects of students' digital literacy.

Figure 1 .

 1 Figure 1. Screenshot of the interactive area of Task 1 (see https://leosiiman.neocities.org/edulearn2019/task1.html).

Figure 2 .

 2 Figure 2. Screenshot of the interactive area of Task 2. (see https://leosiiman.neocities.org/edulearn2019/task2.html).

Figure 3 .

 3 Figure 3. Screenshot of the interactive area of Task 2 after the task has been successfully completed.

Table 1 .

 1 The percentage of participants (N = 156) who received a specified score for Task 1 (max 3 points) and Task 2 (max 2 points).

	Score	Task 1, %	Task 2, %
	0	39.7	50.7
	1	14.1	36.5
	2	17.3	12.8
	3	28.9	-

Proceedings of EDULEARN19 Conference 1st-3rd July 2019, Palma, Mallorca, Spain

ACKNOWLEDGEMENTS

This study was conducted with support of the University of Tartu project "Developing the Teacher Education Competence Centre Pedagogicum at the University of Tartu" financed by the European Social Fund.


Mojtaba Fallahi
email: m_fallahi64@yahoo.com

Sajjad Sayyar

Taher M Abu-Lebdeh

Florian Ion

T Petrescu
email: fitpetrescu@gmail.com

INVISTIGATING THE EFFECTS OF FRP BARS ON THE SEISMIC BEHAVIOR OF REINFORCED CONCRETE COUPLING BEAMS

Keywords: FRP bars, seismic behavior, coupling beams, ABAQUS software, shear walls

Sometimes, it is necessary to install regular openings like windows or doors in the shear walls. Such openings require special reinforcement. There are several methods for reinforcing deep beams, one of which is the use of fiber reinforced polymer bars. In this study, an experimental work on a coupled shear wall has been used to mode the system by using finite element method with ABAQUS software. The finite element model was established based on part of the experimental study and verified with the other parts of the experimental results. The comparison shows good agreement. In the study, three different types of fiber reinforced polymer bars were considered in improving the mechanical and structural behavior of RC coupling beams. Results of the finite element analysis showed the superiority of the CFRP bars in improving seismic behavior of the coupled shear wall comparing to GFRP and BFRP.

INTRODUCTION

Reinforced concrete shear wall system is one of the most common lateral load-bearing systems. It is suitable for seismic loadings. However, it is necessary to install regular openings for windows or doors in shear walls in accordance with architectural considerations and in such cases, reinforced concrete coupling beam is used. The coupling beam, which is an important member in the performance and formation of the coupled shear walls, may be restored and strengthened for various reasons.

There are several methods for reinforcing such beams, one of which is the use of fiber reinforced polymer bars (FRP). It should be noted that FRP bars have high strength-to-weight ratio, but low elastic modulus. It has linear deformation until rupture, leading to brittle failure. Further, concrete members reinforced with FRP exhibit larger deflections and crack widths comparing to steel reinforced concrete structures [START_REF] Ge | Experimental study on flexural behavior of ECC-concrete composite beams reinforced with FRP bars[END_REF].

In recent years, several numerical and experimental studies have been conducted on coupling beams of reinforced concrete coupled shear walls. For instance, Reazpour et al. (REZAPOUR;[START_REF] Rezapour | Macroscopic modeling of the coupled concrete shear wall[END_REF] used Multiple-Vertical-Line-Element-Model (MVLEM) to analyze several types of macroscopic models of coupled concrete shear walls. Their results indicated that the macroscopic wall with moderate connection stiffness has acceptable consistency in terms of static and dynamic responses of the microscopic model. [START_REF] Ding | Analytical model for seismic simulation of reinforced concrete coupled shear walls[END_REF] developed an analytical model for seismic simulation of reinforced concrete coupled shear walls. They proposed new mixed beam-shell model for the seismic analysis of reinforced concrete coupled walls with sufficient efficiency and accuracy on the platform of general finite element software MSC.

Marc. [START_REF] Faridani | Analysis of passively-damped coupled shear walls using continuum-based models[END_REF] assessed coupled shear walls (CSWs) equipped with passive damping systems using the damped continuum models developed as Coupled-Two-Beams (CTB).

His work showed that the developed CTB systems with the shear damping model are suitable tools for the dynamic analysis, and for the preliminary design of

INDEPENDENT JOURNAL OF MANAGEMENT & PRODUCTION (IJM&P)

http://www. ijmp.jor.br v. 10, n. 8, Special Edition Seng 2019ISSN: 2236-269X DOI: 10.14807/ijmp.v10i8.1058 CSWs equipped with velocity-dependent dampers. [START_REF] Cheng | Experimental study of reinforced concrete and hybrid coupled shear wall systems[END_REF] conducted experimental investigation on two approximately half-scale four-story coupled shear wall specimens. The walls were subjected to both gravity and reversals lateral displacement. They concluded that a ductile coupling beam design does not guarantee a ductile behavior of the coupled shear wall system.

On an attempt to investigate the effect of coupled shear walls on the seismic response of tall buildings, [START_REF] Faridani | Investigation of the effects of viscous damping mechanisms on structural characteristics in coupled shear walls[END_REF] A discrete Reference Beam (RB) was first proposed and a Distributed Internal Viscous Damping (DIVD), composed by bending and shear mechanisms, was defined. Their results revealed that the bending and shear damping are somehow efficient where the linear classical damping is incapable to be always a proper mechanism.

Based on previous researches, several methods have been proposed to strengthen RC members. One of these methods is the attachment of advanced composites, such as glass fiber reinforced plastic (GFRP) and carbon fiber reinforced plastic (CFRP), to the tension side of the members (SU; ZHU, 2005).

Although, these composites are generally capable of increasing both the ductility and the load capacity but are prone to peeling and delamination under shear stresses and deboning under cyclic loading. On the other hand, an effective method of replacing steel bars with composite bars have shown considerable strength against corrosion. It is widely used in offshore concrete structures that exposed to salty corrosive water. [START_REF] Cai | Full-scale seismic testing of concrete building columns reinforced with both steel and CFRP bars[END_REF] conducted experimental study on an innovative concrete building column which are longitudinally reinforced with both steel bars and fiber-reinforced polymer (FRP) composite bars.

Despite the various studies on evaluating the seismic behavior of RC coupling beams, there are little researches on the effect of composite bars on the seismic performance of such beams. The aim of this study is to develop a finite element http://www. ijmp.jor.br v. 10, n. 8, Special Edition Seng 2019ISSN: 2236-269X DOI: 10.14807/ijmp.v10i8.1058 model to investigate the effect of composite bars on the seismic performance of coupling beams in terms of ductility, stiffness and overall strength.

MATERIALS AND METHODS: FINITE ELEMENT MODEL DEVELOPMENT

In this study, the experimental work of [START_REF] Su | Experimental and numerical studies of the external steel plate strengthened reinforced concrete coupling beams[END_REF] and Zaidi et al. 1.2-3.7 0.5-1.7 1.9-4.4

The ABAQUS finite element software was used in the modeling. In the modeling process, C3D8R, T3D2 and B31 element types were chosen for concrete, stirrups and longitudinal bars respectively. C3D8R (Figure 2) is a continuum element with reduced integration and hourglass control and capable of simulating concrete cracking in tension and crushing in compression. It is assumed that the uniaxial tension stress-strain relationship is linearly elastic until failure stress ft0 is reached. Beyond the state of the failure stress, the stress-strain response is designed by softening characteristic (Figure 4a). Under uniaxial compression, the response is linear up to the initial yield fc0. After attaining the ultimate stress FCU in the plastic zone, the response of concrete is characterized by the stress hardening followed by strain softening (Figure 4b). Therefore, concrete stresses determined to unload from any point on the strain are:

INDEPENDENT JOURNAL OF MANAGEMENT & PRODUCTION (IJM&P)

    t pl t t c t d E f      1   (1)     c pl t t c c d E f      1   ( 2
)
Where Ec is the modulus of elasticity of concrete. The effective tensile and compressive cohesion stresses of concrete which determine the size of the failure surface are estimated as:

  pl t t c t t t E d f f        1 (3)   pl c c c c c c E d f f        1 (4)
The post-failure behavior of the reinforced concrete can be expressed by means of the post-failure stress as a function of cracking strain εt ck and εc ck which are defined as the total strain minus the elastic strain corresponding to the undamaged material. The tension stiffening data are given in terms of the cracking strains. When DOI: 10.14807/ijmp.v10i8.1058 unloading data are available, programming automatically converts the cracking strain values to plastic strain values using the following relationships (ABAQUS, 2014).

0 1 E f d d t t t ck t pl t       (5) 0 1 E f d d c c c ck c pl c       (6)

VERIFICATION OF THE PROPOSED FINITE ELEMENT MODEL

In this study, the finite element model was established based on the experimental study carried out by [START_REF] Su | Experimental and numerical studies of the external steel plate strengthened reinforced concrete coupling beams[END_REF]. The results of the finite element numerical analysis based on the above procedure are compared with the shear force-chord rotation angle of the experimental specimen and shown in Fig. 6. According to Figure 6, there is an acceptable agreement between experimental and numerical model. The proposed finite element model is capable of predicting the actual response of the structure accurately. Also, it can be seen from the curves that the numerical model is to some DOI: 10.14807/ijmp.v10i8.1058 extent stiffer than the experimental model, which is an obvious consequence of the finite element method.

PRPOSED STRENGHENING METHOD AND RESULTS

Due to the brittle failure modes of concrete, various strengthening methods have been proposed by researchers. These methods can increase the ductility and seismic performance of the structures considerably. In this study, three types of fiber reinforced polymer were used to replace steel reinforcement in order to improve both the mechanical and structural behaviour of RC coupling beams.

The Physical-mechanical properties of FRP used in this study as a reinforcing material are presented in Table 2. In this study, one control model and six different finite element model have been considered based on the strengthening procedures.

Table 3 shows the properties of finite element models based on strengthening method. As can be seen, the development of plastic strain in CFRP-T specimen is considerably higher than BFRP-T which this is due to better performance and efficiency of CFRP bars in comparison with BFRP (The higher the amount of yielded elements, the greater the energy dissipation of the system).

DISCUSSION

In order to evaluate the seismic performance of the FRP coupled shear walls, parameters such as response reduction factor, ductility, energy absorption and initial http://www. ijmp.jor.br v. 10, n. 8, Special Edition Seng 2019ISSN: 2236-269X DOI: 10.14807/ijmp.v10i8.1058 stiffness need to be determined. In this study, the values were determined following [START_REF] Newmark | Earthquake spectra and design: Earthquake Engineering Research Institute[END_REF][START_REF] Newmark | Earthquake spectra and design: Earthquake Engineering Research Institute[END_REF].

Results of these parameters are presented later in this section. Further, it is known that the inelastic behavior of structures is usually incorporated in the design by dividing the elastic spectra by a reduction factor, R, reducing the spectrum from its original elastic demand level to a design level. Structural ductility and overstrength capacity are the crucial constituent in defining the response reduction factor.

According to Patel and his co-researchers (PATEL; AMIN; PATEL, 2014), The response reduction factor can be expressed by equation 7:

R S R R R R     (7)
In which RS, R μ , and RR are the overstrength factor, ductility factor and redundancy factor respectively. According to Petrescu and his co-workers [START_REF] Petrescu | Testing by Non-Destructive Control[END_REF] and Patel, Amin and Patel (2014) these reduction factors can be calculated using equation 8 and Figure 10.

              1 1 V V R V V R V V R

INDEPENDENT JOURNAL OF MANAGEMENT & PRODUCTION (IJM&P)

http://www. ijmp.jor.br v. 10, n. 8, Special Edition Seng 2019ISSN: 2236-269X DOI: 10.14807/ijmp.v10i8.1058 The initial stiffness and energy absorption can also be calculated using bilinear curves. In this study, a MATLAB code was developed to simulate the bilinear envelopes and to calculate the mentioned parameters. As shown in the above figures, the difference between the stiffness of CFRP-T and GFRP-T is significant because. The stiffness of GFRP-T plunged to about half of its initial value. The pattern for seismic factor is approximately the same, however the maximum seismic factor is assigned to CFRP-T at 15.36, while the seismic factor of GFRP-T is 6.68 and the minimum amount has been calculated for BFRP-L at 2.67. Regarding ductility, despite the maximum obtained for CFRP-T but the difference between CFRP-T and GFRP-T decreased noteworthy. Further, the energy absorption of all specimens (Fig 15) is somehow close to each other. CFRP-T has the maximum energy absorption at 6.26E+6.

CONCLUSIONS

From the results obtained by the Finite Element models, the following conclusions can be drawn:

1-Comparing the results of the numerical analysis with the experimental test indicate that there is an acceptable agreement between experimental and numerical results, and thus the finite element model is capable of accurately predicting the actual response of the structure.

2. results of finite element analysis showed that FRP bars positively changed the structural response of RC coupling beams in terms of initial stiffness, ductility, and energy dissipation characteristics.

3. Comparing between the specimens in term of seismic parameters indicated that strengthening of coupling beam with FRP bars has a better seismic response than that for the whole structure.

  investigated the effects of viscous damping mechanisms on structural characteristics in coupled shear walls. They addressed energy dissipation mechanisms to investigate the effects of the internal and external viscous damping on structural characteristics in coupled shear walls.

(

  2017) were utilized to model a coupled shear wall using finite element method with ABAQUS software. The configuration of the model is illustrated in figure 1. Material properties of concrete, reinforcing steel, and fiber reinforcement polymer are shown in tables 1 and 2.

Figure 1 :

 1 Figure 1: Configuration and reinforcement details of model (SU; ZHU, 2005)

Figure 2 :

 2 Figure 2: C3D8R element type T3D2 is a two-node, 3-dimensional truss element used in two and three dimensions to model slender, line-like structures that support only axial loading along the element. No moments or forces perpendicular to the centerline is supported. B31 is a linear 3-dimensional beam element which does not allow for transverse shear deformation. In this element, plane sections initially normal to the beam's axis remain plane (if there is no warping) and normal to the beam axis. The ABAQUS finite element model of the considered configuration is illustrated in figure 3. Further, in this study, concrete damage plasticity model was used to simulate concrete behavior. The material model is a continuum, plasticity based, damaged model for concrete. Damaged plasticity is assumed to characterize the uniaxial tensile and compressive response of concrete as shown in Figure 4.

Figure 3 :

 3 Figure 3: Finite element model

[

  http://creativecommons.org/licenses/by/3.0/us/] Licensed under a Creative Commons Attribution 3.0 United States License

  Figure 5 shows the test setup and loading sequence. Loading was applied by a 500 KN actuator located at the top end with the line of action passing through the beam's center. To simulate the real situation, in which the wall's piers at the two ends of a coupling beam remain parallel under deflections, a parallel mechanism was installed to connect the upper rigid arm with the lower structural steel beam fixed at the floor (SU; ZHU, 2005).

Figure 5 :

 5 Figure 5: Test Set up Source: Su; Zhu (2005)

Figure 6 :

 6 Figure 6: Comparison of shear force-chord rotation curves for experimental and numerical models

  ) and 8 shows load-rotation and load-displacement curves for the situation in which the longitudinalINDEPENDENT JOURNAL OF MANAGEMENT & PRODUCTION (IJM&P)http://www.ijmp.jor.br v. 10, n. 8, Special Edition Seng 2019 ISSN: 2236-269X DOI: 10.14807/ijmp.v10i8.1058 bars of the coupling beam are replaced with glass, carbon, and aramid composite bars. It is obvious that the CFRP bars show the best ability in enhancing the load carrying capacity of the coupled shear wall comparing to FRP bars. By contrast, the GFRP and BFRP bars cause small reduction in the load carrying capacity of the coupling beam in comparison to steel bars. The results of replacing longitudinal bars in the entire structure (coupling beam and shear wall) (Figure 7 b) is approximately similar to Figure 7 a. Comparison between equivalent plastic strain of two specimens is presented in Figure 9 (a, b).

  (a) Results for utilizing FRP bars in coupling beam (b) Results for utilizing FRP bars in whole model

Figure 7 :

 7 Figure 7: Comparison of FEM shear force-chord rotation curves

Figure 10 :

 10 Figure 10: Bilinear curve of the response reduction factor Source: Patel, Amin and Patel (2014)

  Figures 11 and 12 illustrate the derived bilinear envelopes of pushover curve for both steel and CFRP-L. Furthermore, values of the initial stiffness, ductility, seismic (response reduction) factor and energy absorption for all 7 specimens were calculated and the results are shown in Figures 13 to 16. It is clearly obvious from Figure 13 that CFRP-T specimen has shown the highest initial stiffness among the other specimens.

Figure 11 :

 11 Figure 11: bilinear envelope for steel Figure 12: bilinear envelope for BFRP-L

Table 1 :

 1 Material properties

	Material	ID
	Concrete	CB	50.2	43.9
	Steel			Young's modolous
	Steel bar	R8	462.7	212000
	Steel bar	T10	571.0	211000
	Steel bar	T12	529.3	207000
	Steel bar	T16	549.2	210000
	Steel bar	T20	504.1	203000

Table 2 :

 2 Physical and Mechanical properties of fiber reinforcement polymer

	Property	Glass Fiber Carbon Fiber Aramid Fiber
	Elasticity modulus along Fiber (GPa)	35-60	100-580	40-125
	Tensile strength (MPa)	450-1600	600-3500	1000-2500
	Ultimate failure strain, %.

Table 3 :

 3 Numerical Specimens Specification

	SPECIMEN ID Method of strengthening Type of Fiber Bar diameter (mm)
	control	-	-	-
	CFRP-T	Coupling beam	CFRP	20
	CFRP-L	Whole model	CFRP	12,16,20
	GFRP-T	Coupling beam	GFRP	20
	GFRP-L	Whole model	GFRP	12,16,20
	BFRP-T	Coupling beam	BFRP	20
	BFRP-L	Whole model	BFRP	12,16,20

Results of the finite element analysis are presented in form of loaddisplacement and load-chord rotation in Figures

7 and 8

. Figures

7(a