-Access control systems provide a security application for controlling access of persons through controlled gates. The gate, such as a door, can have a lock mechanism for securing the area from unauthorized access. Radio Frequency Identification (RFID) / Near Field Communication (NFC) is a key technology for sensor communication enabling a ubiquitous and pervasive computing network, popularly employed in access control systems. In this paper we investigate a case study about the migration of an old chip card based access control system to this new way of authorizing people, based on NFC tags. To this aim, we propose a Model Driven approach that supports (semi) automatic code generation for enabling the communication between an IoT infrastructure and platforms for Facility Access Management. Specifically, the approach combines the benefits of NFC and Tinkerforge (i.e., an open source hardware platform) technologies with model driven techniques. As a consequence, it allows the reduction of the implementation efforts, by also providing snippets as exemplary code usage, while making the whole development process less error-prone and time consuming.
Access control systems provide a security application for supervising access of persons through controlled gates. The gate, such as a door, can have a lock mechanism for securing the area from unauthorized access. Internet of Things (IoT) is a new concept of integrated network of devices in the field of information technology where devices communicate with each other. IoT security in building access control is a relevant field where building security is implemented through IoT network.
Every device is connected with the related sensors, which trigger the control mechanism communicating with the rest of the infrastructure.
Model-driven engineering [
This paper explores a case study about the migration of an old chip card based access control system to a new way of authorizing people with Near Field Communication (NFC) tags. In the chip card based version of the system, the standard plastic card which contains an embedded microchip has to be physically inserted in a reader to be read; in case data stored on the chip allows the access, it enables the electric door lock.
Usually, the card reader hosts the logic for the access control and, for each equipped door, the code implementing this logic has to be distributed and released on the reader(s). In addition to the access control system, a human resource management system is used to associate a person to the card, to have a registry in case the card gets lost or a check is needed.
Currently, a new way of interaction is provided by NFC
technology [
Tinkerforge [
This system, offering a high degree of abstraction, might ease the technical implementation with less code to be developed with respect to other components. The main advantage in selecting a target technology such as Tinkerforge is that it can be used to build systems interacting with other platforms and customize the access control algorithm for the required Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). purpose, since the code has to be developed. Moreover, the building blocks of the infrastructure can be selected and mounted, based on the requirements, and easily extended.
Despite this selection offers a good trade-off between development and provided functionalities, the code controlling the devices has to be manually written, although some examples and documented APIs are provided on the website.
In this paper, we propose a Model Driven approach that supports (semi) automatic code generation for enabling the communication between an IoT infrastructure and an existing web platform for Facility Access Management. In particular, by combining the benefits of NFC and Tinkerforge technologies together with model driven techniques, the presented approach is able to generate software components, in the selected target language. This way, it allows reducing the implementation effort, also by offering snippets as exemplary code usage, while making the whole development process less error-prone and time consuming.
The paper is organized as follows: section II offers a case study for introducing the domain in which the proposed approach, presented in section III, is applied. Section IV explores the related works and section V draws some conclusions, by also briefly mentioning possible future developments.
In this section, we expose the case study we designed from a project experience with a company. Specifically, the company we deal with it is a gym that is organized in diverse rooms, distributed in several floors of a building. Each room is equipped with different facilities to host specific activities (e.g., training, rehab, pilates). Activities are scheduled in different time slots from Monday to Saturday, with diverse frequencies, and assigned to the available rooms. The clients of the gym can enroll in different courses and/or activities, by choosing different offers and subscriptions. The company wants to exploit the subscriptions that clients hold, to automatically check if they have access or not to each specific room in the building. This way, it can be easily controlled if only authorized clients regularly registered in certain activities, effectively attend it.
We use a metamodeling approach to represent the case study introduced above. To better comprehend the application domain, we engineered the requirements for the system in the metamodel in Fig 1. An AccessControlSystem is organized to manage a list of Activities that can be conducted in the facility, and specifically in the available Rooms in specific TimeSlots. In fact, each room has a Timetable of activities, performed in specific WEEKDAYs and time. The system can register Clients associated to a Person with all the fields for the identification (hidden for lack of space). Each client can be linked to MemberShips with a specific start and end date related to an Activity. The access control system can manage who is authorized to access a room in a specific date and time. This can be derived by retrieving all the activities of a client and by matching them with the timetable of the activities. The authorization and identification of the client
Fig. 1. Access Control Metamodel. then is delegated to the access control infrastructure, that in this case is implemented with the selected NFC technology.
This technology mounted near to the door of a room will identify the tag used by the client and it will trigger the authorization mechanism, by also communicating with the access control system. For instance, the access control system can expose web services or API devoted to this task.
Case Study Configuration. As introduced in section I, Tinkerforge is an open source platform of building blocks belonging to three categories, namely Bricks that, in turn, can control different modules called Bricklets. Then, the communication interface of these building blocks can be extended by using Master Extensions. More precisely, each Brick has one task, which in our case study consists in checking the communication and authorization. Bricks are stackable, in the sense that can be mounted on top of each other by creating a hierarchy.
For simplicity, in this paper we consider non-stackable Bricks.
Bricklets, can be connected to a Brick with a cable and depending on the Bricklet type, different sensors, displays, I/O interfaces can be added. Master extensions are used to change the interface from USB to either Ethernet or WIFI.
To support a basic configuration in our case study, we consider an architecture composed of a single Brick per door (room) and multiple connected Bricklets, namely an NFC reader, a speaker (beeper), a led display and a relay to control the door lock. Relays are switches that can electronically open and close circuits and, in our case study, they control 4 circuits (from which the name of the component quad relay).
Moreover, each client has to receive a NFC tag (card, sticker or bracelet) that has to be enabled for the entrance. Logically, the steps to be performed when entering a room are the following: the NFC reader receives the NFC tag identifier and it checks the authorization with the access control system. In the case in which the authorization is provided, the NFC reader emits a beep by using the speaker, it shows an authorization message depending on the architect and specific needs. To be clear, on the display, and it enables one of the channels of the one brick can be equipped with display and another with a relay controlling the door lock. If the authorization is denied, speaker, depending on the noise level of the area. In particular, instead, the NFC reader emits a sound and displays the error this will make the initialization code different from a brick to message. All these operations can be implemented by using another. the Tinkerforge API.
In the following, we show the Java code that must be manually written, in the absence of automatic code generation, to implement the explained control logic among the various sensors and bricklets, for our case study. In listing 1 we report the Java code developed for the logic of a single brick. This initialized Brick has UID (identifier) hr4tx and will be powered by PoE (power over ethernet) extension, with ip address 192.168.1.2 (localhost in our LAN) for communication.
1 package tinkerForgeGen; 2 3 import com.tinkerforge.*; 4 ... 5 public class Brick_hr4tx implements Runnable { 6 Thread thread; 7 String brick_UID="hr4tx"; 8 String HOST_uqB = "192.168.1.2"; 9 NFCReader nfc_reader_uqB; 10 int PORT_uqB = 4223; 11 String readerUID_uqB = "uqB"; 12 Short currentTagType_uqB = BrickletNFC.
TAG_TYPE_MIFARE_CLASSIC; Since this brick has basically different types of connected bricklets, e.g., NFC Reader, QuadRelay, etc, lines 9-20 declare the variables needed for initializing these modules. For instance, lines 9-12 declare the NFC Reader variables, lines 14-17 the ones for the relay and the following lines 19-20 the variables for the speaker and the display. Then, in the constructor of the Brick, lines 22-27, all the bricklets part of the chosen architecture are initialized using Java classes included in the project that we developed. It is worth noticing that each brick can be configured with different bricklets, 6 7 8 9 10 11 12 Listing 2 reports a snippet of the method written for the QuadRelay component, to open and close the selected channel.
This method basically takes as input the position of the channel we want to open and it blinks for the selected timelapse (line 12). Then, it opens the relay and further closes it. We omit the Java classes initializing the OledDisplay and the Speaker for lack of space.
1 public class NFCReader extends MyBricklet{ 2 3 public void initializeReader(...) { 4 5 IPConnection ipcon = new IPConnection(); 6 final BrickletNFCRFID nr = new BrickletNFCRFID(
readerUID, ipcon); 7 8 ipcon.connect(HOST, PORT); // Connect to brickd 9 10 // Add state changed listener 11 nr.addStateChangedListener(new BrickletNFCRFID.
StateChangedListener() { 12 public void stateChanged(short state, boolean idle)
{ try { if(idle) { nr.requestTagID(currentTagType); Thread.sleep(500); } if(state == BrickletNFCRFID.
STATE_REQUEST_TAG_ID_READY) { // getting tag id BrickletNFCRFID.TagID tagID = nr.getTagID(); String tag = Integer.toHexString(tagID.tid[0]); for(int i = 1; i < tagID.tidLength; i++) { tag += Integer.toHexString(tagID.tid[i]); } try { System.out.println("Put Your logic here, detected
tag "+tag+ " by reader: "+readerUID); for (MyBricklet myBricklet : bricklets) {
Lines 29-38 of listing 1 reports the main task of the brick and its main bricklet, namely the NFC reader (whose code is reported in listing 3). The NFC component is initialized with a state change listener that will be executed when a NFC tag touches the NFC reader (lines 12-39 of listing 3). In this case, line 27 prints a message saying to customize this method with a conditional statement for authorizing or not the tag, and it starts the communication with the other bricklets. Line 35 reports a call to the OpenRelay method that will execute the method reported in listing 2, previously explained (the default channel to be opened is specified in the initialization).
The rest of the code, which is omitted here, will print on the display a message reporting the tag id of the client and it will trigger the sound emission of the speaker. The state changed listener assures that the NFC tag will remain waiting for the next tag, except for possible exceptions. Lines 27-36 (of listing 3) should be customized in order to support the communication with the access control system, for instance by making a REST call with the tag id to check if it is authorized. 1 package tinkerForgeGen; 2 ... 3 public class InitializationModule{ 4 // Initialize the modules with multiple threads 5 public static void main(String args[]) throws
Exception { try {
Brick_hr4tx brick_hr4tx= new Brick_hr4tx(); brick_hr4tx.start(); ...
Brick_d32d3 brick_d32d3= new Brick_d32d3(); brick_d32d3.start(); } ...
Of course, the numbers listed in table I can easily grow depending on the size of the infrastructure, and developers will tend to copy and paste snippets from a component to another. This activity is error-prone and time consuming, and it might be detrimental to the whole infrastructure. However, it can be automated by exploiting model driven techniques. To alleviate this issue, in section III we present a model driven approach to partially automate this process.
To better explain the design of the chosen infrastructure and to enable the code generation, we engineered the Tinkerforge architectural modules in a metamodel, partially depicted in Fig 2. We omit other modules we did not use in our running example, to make the picture readable. An Infrastructure is composed of Bricks, to which an application can connect through its ip address. All the building blocks are identified with the UID. A brick can be connected to Bricklets, that can be classified in various types, for instance In/Out devices, Sensors and Extensions. The NFC Reader is of type Sensor and it has to declare which TagTypes it reads for the targeted application. The Speaker (beeper) can be set with specific beep duration, volume and frequency. The QuadRelay, instead, requires the time lapse for opening the channel set to true. Also NFC tags are part of this metamodel with a unique identifier and all the sectors to read and write. The structure of a tag is divided into sectors which are composed of blocks, but since the application is simply reading the UID of the tag we do not read and write the sectors (for this reason is omitted from the metamodel).
Eventually, listing 4 is responsible for starting the threads for each brick in the infrastructure. In our case study we considered two bricks, but there are of course more in real cases. This simple infrastructure require basic knowledge of Java (since it has been chosen as target language) and the Fig. 2. TinkerForge metamodel code implemented for the presented basic functionalities can beTehsetiminaiteiadliiznattieornmmsofdulilneestroofncgolydede(LpeOnCd)s aosninthetabnluemIb:er At this point we have a metamodeling layer supporting the of bricks involved in the infrastructure, as the first rows depend definition of two types of models: the infrastructural model from the number of bricklets mounted per brick. We created (conform to the metamodel in Fig. 2) and the access control a Java class per brick, since each brick can vary the mounted system model (conform to the metamodel in Fig. 1). The missbricklets, and generic class for the different types of bricklet. ing information at this stage is about how the infrastructure is related to the concepts we have in the access control system.
For instance, how the room’ door is controlled by a specific
brick and, in particular, an NFC reader. Moreover, we can
also relate NFC tags to the clients in order to keep track of
the authorized access. To do that, we conceived a weaving
metamodel, namely Interoperability Weaving metamodel, that
is shown in Fig. 3. A weaving model is a model specification
used to capture relationships between model elements [
In this metamodel, we basically have two types of links:
InfrastructureLink, defining how the building blocks of our
infrastructure can be related to concepts of the access control
system, e.g., room and brick; AssociationLink defining that a
specific tag has been assigned to a client. This metamodel
can be enriched with other types of links and it is still
under development. This weaving approach enables a set of
automatism that will be discussed in the rest of this section
and that we summarize in Fig. 5. Basically, the process starts
from the definition of the models of the infrastructure (see
Fig. 2) and the access control system (see Fig. 1). These two
models can be linked with an Interoperability Weaving Model
defining the relationships between them.
have the metamodeling layer proposed in previous sections. A
code generator has been developed to automatically generate
the code interacting with the Tinkerforge APIs as (manually)
defined in section II. In fact, an Acceleo code generator has
been developed for creating Java code for this application, but
it can be easily extended to support other target languages, e.g.,
PHP. Acceleo1 is a template-based technology to create custom
code generators. This code generator takes as input the
Interoperability Weaving Model, it navigates to the left and right
models to get the right model elements and it generates the
code interacting with the Tinkerforge API, exactly as shown
in section II. For the sake of clarity, the access control model
can be used to generate part of the web application managing
the data, as well as the SQL script of the application [
Infrastructure MM Infrastructure
Model Modeling Platform reflects
PHP Java
...
Interoperability Weaving MM
Access Control
System MM Interoperability Weaving Model
IN Code Generator generates
Domain Engineering Access Control System Model
SQL Script for testing generates Real Infrastructure
Web Platform
Database
Fig. 4 reports a screenshot of the weaving editor, where an interoperability weaving model has been created to link the exemplary infrastructure with a simple access management model. The dotted lines highlight how the concepts have been linked: for instance, the Brick with UID hr4tx has been linked to Room_A. Room A hosts an activity called Training on Thursday from 10:00 to 13:00 (visible by exploring the property view of the model). Moreover, we have some associated tags, e.g., the tag with id 372112f5 is associated with client 0, aka John Doe. Not all the properties of the model elements are visible from this screenshot, since we tried to highlight the links defined in the weaving model.
A general process depicting the overview of the approach is reported in Fig. 5. At the Domain Engineering phase, we
The code generator is composed of multiple templates. The main template is called generateElement (listing 5) and it is responsible for generating the initialization file of the modules.
1 [module generate(’http://tinkeforge.org/ interoperability’,’http://tinkeforge.org’,’http:// cs.ssi.it/access-control’)] 2 3 [template public generateElement(interoperabilityModule
: InteroperabilityModule)] 4 [comment @main] 5 6 [ if((interoperabilityModule.links->select(l|l.
oclIsKindOf(InfrastructureLink)).oclAsType( InfrastructureLink).brick.connectedDevices->select( e|e.oclIsKindOf(NFCReader )))->size()>0) ] 7 [generateNFCReaderCode.../]
8 [/if] 9 [ if((interoperabilityModule.links->select(l|l. oclIsKindOf(InfrastructureLink)).oclAsType( InfrastructureLink).brick.connectedDevices->select( e|e.oclIsKindOf(QuadRelay )))->size()>0) ] 10 [generateQuadRelayCode.../] 11 [/if] 12 ... 13 [generateInitializationCode(interoperabilityModule)/] 14 [/template]
Indeed, for each interoperability link of the input weaving, it selects the infrastructure links and for each type of bricklets, connected to the main brick, it generates the corresponding Java class in the workspace. For instance, if an Infrastructure Link is connecting a room to a brick containing an NFCReader and a QuadRelay, it will generate NFCReader.java and QuadRelay.java (shown respectively in listing 3 and 2). The final call at line 13 in listing 5 is responsible for generating the threads initialization in the main java file invoking the template in listing 6. Here, for each infrastructure link it creates the Brick java class containing the code explained in listing 1 and it generates the code for initializing the bricks contained in the declared infrastructure model, in lines 5-6 in listing 6 (see listing 4 for the produced code).
6 7 8 9 10 11 } 1 public static void main(String args[ ’[’ /][ ’]’ /]) throws Exception { 2 try { 3 [for (link : InfrastructureLink | interoperabilityModule.links->select(l|l.
oclIsKindOf(InfrastructureLink)))] 4 [createBrickComponent(link)/] 5 Brick_[link.brick.UID/] brick_[link.brick.UID/]= new Brick_[link.brick.UID/](); brick_[link.brick.UID/].start(); [/for] } catch (Exception ex) { ex.printStackTrace(); }
The last template that we report for completeness is createBrickComponent, triggered by line 4 of listing 6. Listing 7 reports a snippet of this template, where first of all a selective list of import is generated, depending on the real building blocks declared in the infrastructure. This selectively generates the real package imports needed by the program (see for example lines 1-3). Lines 7-14 is the template part responsible for generating the variables initialization for each type of bricklets connected to the brick and then the constructors of the bricklets are called from lines 17-19 (this code is for QuadRelay, it follows for the other types of Bricklets). Next, it follows the generation of the run method, that will be executed by the running thread. In this thread the main task will be to read the NFC tags and if other bricklets are connected using them to orchestrate the infrastructure. The code responsible for the state changed listener, which has been previously shown in listing 3, will be generated in the NFCReader.java file that will be called by the initializeReader in line 32 of the generator (listing 7). The code in lines 27-29 will add to a list of available bricklets the devices connected to the brick, that will be available in the NFCReader code, so that the developer can customize his/her own logic. This specific generated code will be customized with respect to the real infrastructure of connected bricklets, completely specified at the model level.
By executing the generated code, we managed to test the communication mechanism with the infrastructure we modeled. In fact, the screenshot of the log in Fig. 6 (top side) reports the printed detected tag id, e.g., 372112f5, corresponding to a specific client of the access control system. To verify this, we also executed an OCL query on the access control system model in order to retrieve information about if the tag has been assigned to someone and if this person is actually authorized. The bottom part of Fig. 6, indeed, reports the OCL query executed crossing the detected tag by the NFC reader with UID uqB with the clients and activities of the room infrastructured with that brick. In this case, the query returns positive authorization for the client John Doe, which is assigned to that tag in the model. This part has to be integrated in the logic of the application, for instance by including an API call to the authorization url of the access control system. This part has to be manually specified since the possible logics can be multiple, for instance, grant everyone and log the information or check the authorization.
Tinkerforge usage. The presented approach is based on the Tinkerforge platform. Currently, the actual implementation of the specified metamodel does not comprehend all the possible bricklets that Tinkerforge provides. The code generation process has been tested only for the devices we currently have, by making the Tinkerforge platform underused. However, the approach we proposed is general and it can be further extended to support the complete set of bricklets. In particular, to enable the support for a new type of module, it requires two main steps: (i) the development of the code for the new module, which should follow the specification given on the documentation, and (ii) the reverse engineering to placeholders of the code generator, where the code should refer to the specified domain concepts. This process represents a sort of reverse engineering, which the modeler should apply for each target language that has to be supported, in the case of multi-platform code generation.
Further design models. The models created with the engineered metamodel allow the specification of structural characteristics of the infrastructure. The generated code acts as sample code that the developer might customize to address the logic of the application. For instance, the model does not contain the interaction between the retrieved NFC tags and the authorization system, that can expose an API making authorization data available. The logic of the authorization mechanism, and its conditional statements, might be supported with behavioural models, e.g., sequence diagrams, in order to be able to generate the complete application. As future work we plan to extend our approach to embed these models.
Web application design. From the interoperability weaving
model shown in Fig. 3 we could also generate part of the
web application that acts as human resources and facility
management system, with the related API for the
authorization mechanism. This topic has been largely addressed,
e.g., in [
Access Control Systems provide a security application to
check entries via controlled gates to restricted access areas.
Their application is foreseen in both out-door [
Model Driven Engineering (MDE) has been already adopted
to deal with the challenges of the IoT domain (e.g.,
heterogeneity, reusability of software artifacts) [
(Semi) Automatic code generation for architectural models
has gained a lot of attention in recent years, even in the IoT
domain. In [
Domain Specific Languages (DSLs) have been largely
adopted to software development in different contexts [
In conclusion, in our approach we profit from the before mentioned benefits of MDE, DSL and code generation based approaches, by additionally combining them with the use of the Tinkerforge platform. This allows the approach to further push and increase modularization, abstraction and code generation features. Moreover, the provided infrastructure is open and extensible to different technologies and device types, besides RFID/NFC.
In this paper we presented a Model Driven approach supporting the (semi) automatic code generation for enabling the communication between an IoT infrastructure and an existing web platform for Facility Access Management. This work has been triggered by the need for migrating an old chip card based access control system to a new way of authorizing people with NFC tags. In particular, the approach we provide enables the generation of software components in the selected target language (e.g., Java), by also offering snippets as exemplary code usage, when possible. The objectives of the presented approach are manifold: (i) relieving developers from the inherent complexities of heterogeneous IoT devices, protocols, networks, also in view of a multi-platform evolution of the approach; (ii) making the whole development process less error-prone and time consuming, while exploiting code generation. As future work, we plan to address the limitations discussed in section III-A and to make the generative approach multi-platform, by targeting further languages besides Java, through a wider exploitation of the Tinkerforge platform.