Towards Context-aware Border Security Control
Boris Shishkov
and Dimitris Mitrakos
Institute of Mathematics and Informatics, Bulgarian Academy of Sciences, 1113 Sofia, Bulgaria
IICREST, 53 Ivan Susanin Street, 1618 Sofia, Bulgaria
Department of Electrical Engineering, Aristotle University of Thessaloniki, 54124 Thessaloniki, Greece,
Keywords: Enterprise Modeling, Model-driven Engineering, Context-awareness, Border Security, SDBC.
Abstract: Context-aware systems allow for adapting the system behaviour to the context situation at hand and we have
seen good applicability of context-aware systems in domains, such as Mobile Health. Even though this could
also be useful for the Border Security domain, applying context-awareness in this domain is not trivial since
the possible context situations are numerous and difficult to predict. Still, context-aware Border Security
systems are needed as a possible way to overcome the inevitable shortage of resources along the borders.
Smooth and fast border crossing for travellers, in combination with adequate level of security, can be achieved
if: (i) at any moment, the context situation is properly captured; (ii) there is potential for behaviour and
resources (from the Authorities’ side) corresponding to each possible context situation. The context situation
capturing is about sensors, data streaming, and so on. Establishing the right behaviour / resources is about
enterprise modeling and business rules, and it is also about automation that assumes in turn integration of
software applications in the overall Border Security system. In this position paper, we address all that, inspired
by the SDBC Approach, Enterprise Ontology, Semiotic Norms, and the principles of Context-aware Systems.
Reporting research-in-progress, we only present our way of modeling and we identify several domain-specific
concerns that are related to the application of the built models. We also provide a list of recommendations
that are expected to be useful with regard to possible Border Security system developments.
Most software systems need to be adequately
integrated in their enterprise environment comprising
enterprise modules, human agents, and even already
running software applications. Hence, traceability
and possible mappings are often needed between a
piece of software and an enterprise module and vice
versa (Shishkov, 2016); this we call enterprise-
software alignment (Shishkov and Janssen, 2016).
The SDBC Approach allows for realizing such an
alignment in a component-based way (Shishkov,
2005), justifying that software specification should be
based on corresponding enterprise models. This can
be achieved when we have sufficient knowledge of
the enterprise environment and this environment is
more or less stable. Nevertheless, if we have a
constantly changing enterprise environment, we
would face a new challenge – the challenge of
handling adaptability. This means adapting to the
surrounding situation in two directions: firstly, if the
enterprise environment is changing, then the
enterprise modules “inside” should be changing in
turn; secondly, if the enterprise environment is
changing, then the “behaviour” of the software
applications running inside the enterprise should be
adapted as well. Said otherwise, we should be able to
adequately establish the situation at hand and provide
the right enterprise / software behaviour accordingly.
This was called context-awareness in research
addressing such adaptability-related challenges in the
domain of Mobile Health (AWARENESS, 2006). An
example is Tele-Monitoring: a patient is being
monitored from distance, using mobile technology;
there are several possible-to-occur situations, each of
them being easy-to-capture distantly; then action is
triggered, corresponding to the captured context
situation. Thus, we argue that context-awareness is a
solution and is easy-to-apply only if we have a limited
number of possible-to-occur situations. However, in
the current position paper, we address a domain
characterized by MANY possible-to-occur situations:
this is the Border Security domain. In
particular, we are interested in the monitoring of
illegal migration and in combatting related crime
Shishkov B. and Mitrakos D.
Towards Context-aware Border Security Control.
DOI: 10.5220/0006223802070212
In Proceedings of the Sixth International Symposium on Business Modeling and Software Design (BMSD 2016), pages 207-212
ISBN: 978-989-758-190-8
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
(and goods smuggling). Guarding along country
borders by electronic means, using various channels:
infrared images, visible images, proximity sensors,
and so on, followed by some kind of intelligent data
fusion algorithms, has been addressed in several
European Projects, such as the European FP7 Project:
“Protection of European Seas and Borders through
the Intelligent Use of Surveillance” (PERSEUS,
2015) and the European EBF Project: “Land Border
Surveillance – Strengthening of Reaction Capacity”
(LandBorderSurveillance, 2012). Still, those efforts
appear to be insufficient as it can be seen from the
severe border problems in Greece and Italy, in 2015-
2016 (FRONTEX, 2016). We recognize the need for
better interoperability with regard to the existing
national border security platforms and systems. We
do agree that innovative capabilities are needed,
including trans-national exchange of available and
useful information, as it has been discussed in the
above-mentioned projects. Nevertheless, we argue
that those would only be part of the solution related
to the challenge of improving Border Security,
supported by (software) technology. We claim that
context-awareness is not applied of full value at the
borders and we claim that context-aware Border
Security systems would make a difference in the
direction of improvement. At the same time, we go
back to our previous conclusion, already mentioned,
that it is not straightforward applying context-aware
solutions in the Border Security domain. Hence,
research is needed on Context-Aware Border Security
(CABS) control, as a possible way to overcome the
inevitable shortage of resources along the borders (it
would be difficult for a country to supply persons and
equipment at every potentially risky border point). A
CABS system would guarantee adaptability with
regard to the situation at hand – persons and
equipment would only be supplied at the spot where
they are needed and in the moment when they are
needed. Of course, if total “tension” appears at all
risky border points at the same time, such an approach
would “crash” but this is similar to the situation of all
customers of a bank claiming back their deposits at
the same time. Such situations are considered to be of
low probability to occur and are thus left beyond the
scope of this paper.
Hence, we claim that smooth and fast border
crossing for travellers in combination with adequate
level of security can only be achieved if:
(i) at any moment, the context situation is properly
(ii) there is potential for behaviour and resources
(from the Authorities’ side) corresponding to each
possible context situation.
The context situation capturing is about sensors, data
streaming, and so on. Establishing the right behaviour
/ resources is about enterprise modeling and business
rules, and it is also about automation that assumes in
turn integration of software applications in the overall
Border Security system.
Further, because of the increased complexity with
regard to Border Security situations and occurrence
probabilities, we need to address data aspects (going
beyond just interoperability and information
exchange, see above). Ways to capture data, quality
of data and the probability that the captured data is
correct, reliability, versioning, privacy, and so on, are
of importance as well. Hence data analytics is to be
integrated in the enterprise modeling and also in the
software development in order to facilitate context-
awareness, especially in the Border Security domain.
In this position paper, we address all this, inspired
by the SDBC Approach (Shishkov, 2005), Enterprise
Ontology (Dietz, 2006), Semiotic Norms (Liu, 2000;
Shishkov et al., 2006), and the principles of Context-
aware Systems (AWARENESS, 2006).
Reporting research-in-progress, we only present
our way of modeling (Section 2) and we identify
several domain-specific concerns that are related to
the application of the built models (Section 3). We
also provide (as part of the conclusions) a list of
recommendations that are expected to be useful with
regard to possible Border Security system
As mentioned above, we address the challenges of
deriving software and integrating it in its enterprise
environment, inspired by the SDBC Approach
(Shishkov, 2005). This in turn assumes reference to
the theories of LAP – Enterprise Ontology (Dietz,
2006) and Organizational Semiotics (Liu, 2000);
those are briefly outlined in another paper published
in the current proceedings (Shishkov & Janssen,
2016). The idea behind SDBC is that (re-usable)
enterprise modeling constructs (called “Business
CoMponents”) are identified and reflected in
corresponding software specification models to be in
turn decomposed in terms of models of software
components. SDBC is consistent with the principles
of Model-Driven Engineering – MDE (Schmidt,
2006): building a technology-independent model
goes first, then it is to be decided what would be
automated, and in the end is the software derivation.
This is the “basis”, no matter if we go for developing
a context-aware system or a system that is not
Sixth International Symposium on Business Modeling and Software Design
context-aware – in order to contribute especially in
the direction of context-awareness and particularly in
the Border Security domain, we need to have a
“valid” basis to start to build upon. For that we take
SDBC not only because developing this approach is
part of our previous work but also because SDBC has
been validated by means of case studies carried out in
the domains of Finance and Healthcare.
Further, the SDBC Approach and the principles of
MDE were successfully applied in specifying
context-aware systems in domains, such as Mobile
Nevertheless, as mentioned already, the Border
Security domain assumes greater complexity because
of numerous possible situations and prediction
difficulties. Further, what is observed at the border is
a “mixture” of personnel and devices, subject to
numerous rules and functionalities (FRONTEX,
2016), and it is not trivial approaching this in terms of
technology-independent models, automation, and so
on. This is because some (intuitive) tasks can only be
realized by humans while other (surveillance) tasks
can only be realized by devices, to give just an
example. Hence, we need to “adapt” SDBC to the
peculiarities of the Border Security domain. SDBC
goes “top-down”, from a “bird-view” enterprise
model through delimitation with regard to the
software system –to-be, to implementation.
Nevertheless, for specifying a CABS system, we
propose to go “middle-out”, as exhibited on Figure 1,
and we adapt the application of SDBC accordingly.
Figure 1: CABS – Way of Modeling.
On the Figure: “GM” stands for “general model”,
“CM” stands for “conceptual model”, “ITM” stands
for “IT model”, “HM” stands for “humans model”,
“AM” stands for “aspect model”, and “DA” stands for
data analytics”.
We propose to go “middle-out” because in the
Border Security domain, it seems most pragmatic to
start with modeling “what is there” (a mixture of
person-tasks, device functionalities, and so on to be
seen at the border) – such a model we call a general
model (GM). No other model that would inevitably be
abstract, would allow for grasping everything
correctly and also communicating it adequately with
all relevant stakeholders – this is claimed to be of
great importance particularly for the Border Security
domain. Just as an example of GM, we consider a
typical point at an external EU border, the border
between Bulgaria and Turkey (FRONTEX, 2016),
and we take an “imaginary” view on things that may
be seen at a border point – see Figure 2.
Figure 2: GM Example.
As seen from the Figure: there is a border fence
and border police officers patrolling along the fence;
there are cameras attached to the fence, which realize
crowd monitoring and there are mobile cameras
attached to drones; there are finger-print devices that
can be used by police officers for personal
identification; there are (networked) computers
running and streaming all sensor raw data, and also
processing it by applying data fusion algorithms (for
example), allowing “higher-level” reasoning, and so
on. Hence, we claim that such a model should be the
starting point in specifying a CABS system.
We use the GM as basis for deriving a CABS-
related classification of concepts – this we call a
conceptual model (CM) – see Figure 1. This way of
“arriving” at the CM guarantees that our further
system development activities would be “grounded”.
The human agent concept and the device
concept appear to be essential within the CABS
conceptual model (Figure 3). That is because the
CABS general model suggests that anything that can
be observed at the border either relates to a personal
(human) role or to a functionality delivered by a
device (equipment). Further, among the human
agents at the border (besides the persons who are
crossing the border and are thus left outside the scope
of the CABS system) are customs officers and
police officers, while among the devices one
could observe at the border are sensors,
Towards Context-aware Border Security Control
computers, and vehicles. Sensors in turn could
be audio sensors and video sensors, while
computers could be servers and personal
computers, and vehicles could be cars and
drones. And so on. This is just as an example on
how a CM can be derived, based on a GM.
human agent
... vehicle
Figure 3: Deriving a Conceptual Model.
Such a conceptual model is the necessary starting
point in an SDBC software development but also if
one would just need to build an enterprise model.
What goes next, as it can be seen from Figure 1,
is splitting in two, namely: humans model and IT
model. Said otherwise, all that concerns persons at the
border is put on one side and all that concerns devices
at the border is put on another side. We do not mix
this up even though in enterprise modeling we often
mix up activities that are realized by humans and
activities that are automated, realizing that it is
possible to further automate activities currently
realized by humans. For example, the SDBC
Approach was used to specify the automation of what
a human actor (in particular: Insurance Broker) was
doing, for the sake of “replacing” humans by software
(Shishkov, 2005). In such cases, it is straightforward
putting together in the model issues that concern
human actors and issues that concern non-human
actors. This is claimed to be nevertheless
inappropriate with regard to the Border Security
domain and that is why the CABS conceptual model
strongly distinguishes between human agents and
devices (see Figure 3). Hence, as according to Fig. 1,
we model the human entities and processes (HM), and
in parallel, we model the devices-related entities and
processes (ITM).
That is because devices at the border (on one
hand) capture raw data, stream data, run algorithms,
and so on, and all those issues concern the electronics
features of the devices, not even so much the software
in some cases; further, those societally elementary but
computation-intensive tasks assume nothing like real-
life communication, intuitive behaviour, pro-activity,
and so on. Persons at the border (on the other hand),
such as border police officers, for example, are often
valued especially for their intuitive behaviour,
enriched by many years of experience. It is the person
(not the device) who can “smell in the air” anything
wrong and possibly trigger a check without even
being able to explain why. This is in contrast to other
domains where sometimes a task can equally be
completed by a human actor or by a non-human actor.
We claim that at the border, what persons do and what
devices do are “two different Worlds”.
What is next (see Figure 1) is the modeling
elaboration – each of the two models (HM and ITM)
is to be elaborated; having provided just a
classification of concepts is not enough - statics
(entities and their relationships), dynamics (processes
and states), and so on, need also to be provided as
elaboration. Such elaboration models are called
aspect models (AM). We build those models, inspired
by the four modeling perspectives of the SDBC
Approach: Structural Perspective that reflects entities
and their relationships (Dietz, 2006); Dynamic
Perspective that reflects the overall business process
and the states of each entity (evolving accordingly)
(Van der Aalst, 2011); Data Perspective that reflects
the information flows across entities within the
system and flows reaching beyond the system’s
boundary (Shishkov, 2005); Language-Action
Perspective that reflects real-life human
communication and expression of promises,
commitments, and so on (Shishkov et al., 2006).
Hence, as elaboration, we build structural models,
dynamic models, data models, and language-action
models – those are four aspect models. We proceed
as follows:
With regard to the HM we do all four elaborations,
With regard to the ITM, we do all except the last
one – the language-action model, because devices
cannot express commitments, do promises, and so
on, using language.
Then, after having elaborated the HM and the
ITM in terms of aspect models, we need to
“synchronize” between the two, as depicted in Figure
1. By bringing together the two structural models, we
establish all relationships between human entities and
device entities, by bringing together the two dynamic
models, we establish if any human action requires as
pre-condition a corresponding device action to be
completed (and vice versa), and so on. A question
could be asked why was it necessary to firstly split
and then synchronize. By firstly splitting in two
(persons and devices) and then bringing them
together, we guarantee for:
Sixth International Symposium on Business Modeling and Software Design
Adequate modeling, because each model is being
generated based on the right background (when
modeling humans, we consider humans and when
modeling devices, we consider devices);
Exhaustive modeling, because in the end the “two
parts” are brought together.
Then comes the data analytics (DA) – see Fig. 1
and it is important not to confuse this with the “data
perspective” of SDBC, reflected in deriving the
aspect models. This perspective has a purely
functional drive – we consider the data flows as part
of the delivered functionality (for example, a balance
needs to be checked, before allowing a person to
withdraw money from his/her account). The DA, on
the contrary, has a non-functional drive and is
crosscutting. For example: (i) Extracting a face image
of a person, allows for realizing activities on that
basis but is it legally correct to do so and if not, is this
information an “input” or not? (ii) If what we get as
sensor raw data has, say 80% trustworthyness, what
we do forward? Those are just two examples and we
would also mention data versioning, obsolete data,
wrong approximations, and so on. Nevertheless, just
staying aware of those issues is not helpful – we need
to address them functionally (even though in essence
they may be non-functional). A possible way to do
this is by applying Semiotic Norms – see another
paper in the current proceedings (Shishkov &
Janssen, 2016), for example (on considering crowd
Whenever the System has established a situation
if the level of trust is less than 75%
then the System
is obliged to check also another source.
And in the end comes re-engineering – Figure 1,
and the line there is dashed, to indicate that it is not
always needed to re-engineer the system. Still, if the
built models help in identifying inconsistencies, re-
engineering could follow straightforwardly.
This is our proposed way of modeling CABS
systems, in line with the SDBC Approach and as
already mentioned, in the next section, we reason
about the application of the CABS models, by
identifying several concerns related to such an
Being successful in the modeling phase is crucially
important, no question about this, but it is equally
important to be successful in reflecting the models in
architectures that are an adequate basis for
implementation. In this regard, we have identified
several domain-specific concerns, not claiming
exhaustiveness nevertheless, which are presented in
the current section; those concerns are intuitive
behaviour, devices’ technical restrictions, security,
and privacy.
3.1 Intuitive Behaviour
As mentioned before, a border police officer is
sometimes especially valued for his/her capability to
be intuitive with regard to a situation, applying a
“sixth feeling” in deciding what to do. In our view,
this is nearly impossible to capture and reflect in
models. This means in turn that an important Border-
Security-related “asset” would inevitably remain
outside the “scope” of a CABS system.
3.2 Devices’ Technical Restrictions
Often a device at the border is a piece of hardware and
its electronics would often be restrictive with regard
to the ways in which it could be used. If a software
application would have to “bridge” the device to the
system, then in-depth knowledge on the electronics of
the device would be a must – this complicates the job
of enterprise modelers and software designers. Those
restrictions are nevertheless not only electronics-
related – a drone, for example cannot “carry” more
than half a kilo and cannot stay in the air more than a
certain amount of time – such restrictions should be
taken into account as well.
3.3 Security
A CABS system should follow highest security
standards, “higher” than even in Banking because a
Border Security failure may lead to dramatic
consequences for hundreds and thousands of people.
This assumes not only establishing advanced
computer networking but also “guaranteeing” what
human actors would do (or not do). This is to be taken
into account and in our view, it is very difficult to
actually establish and maintain so high security
standards in two perspectives - personal and
3.4 Privacy
A CABS system should be a privacy-sensitive system
because of a number of privacy-related risks at the
border, concerning both border police officers and
Towards Context-aware Border Security Control
persons crossing the border. For example, it should
not be possible that terrorists whose crossing the
border was obstacled by a border police officer, are
able to later on identify the police officer. Another
example: it should not be possible that crowd
monitoring information is used later on in another
context, with regard to the monitored person(s).
Those issues are “burdened” with many legal aspects
and what makes things even more complicated is that
legislation differs from country to country, even
inside the EU.
Those are four important concerns, related to the
application of the CABS models and they indicate
that there are issues beyond enterprise modeling and
software design, that need to be taken into account
and have great potential impact on the CABS system
There is room for improving both the effectiveness
and efficiency of the control at the external EU
borders, and context awareness is a desired feature in
this regard. Nevertheless, the development of
context-aware Border Security systems is not trivial
because of numerous possible-to-occur situations and
prediction difficulties, and because of person-specific
(intuitive) and device-specific (algorithmic)
behaviour patterns. A “middle-out” realization of the
SDBC Approach is proposed to tackle this, coming
through the derivation of a general model, a
conceptual model (split in two – a humans model
(HM) and an IT model (ITM)), modeling
elaborations, a synchronization between HM and
ITM, and enrichment in terms of data analytics.
Persons’ intuitive behaviour, the technical restrictions
of devices, security, and privacy are among the
concerns related to the application of those models.
Inspired by the aim of furthering this research, we
would stick to the following recommendations that
we identified accordingly:
A CABS system should be modeled as a human-
centric system because the intuitive behaviour of
border police officers is and will be of great
importance at the border.
In using devices, the quality-of-data is to be of
great importance for a CABS system, and this
issue is to be also handled functionally.
A CABS system is to be modeled as a context-
aware system where the delivered system
behaviour depends on the context situation at
A CABS system is to be based on an enterprise
model that is split in two – one part featuring
persons and another part featuring devices; a
synchronization between the two is essential.
Security and privacy are issues that are to be taken
into account additionally, in order to have a CABS
system of real value.
AWARENESS, 2006, the website on the Freeband
Dietz, J.L.G., 2006. Enterprise Ontology, Theory and
Methodology. Springer-Verlag, Berlin Heidelberg.
FRONTEX, 2016, the website on the European Agency
LandBorderSurveillance, 2012, the website on the EBF
LandBorderSurveillance Project:
Liu, K., 2000. Semiotics in Information Systems
Engineering. Cambridge University Press, Cambridge.
PERSEUS, 2015, the website on the European FP7
PERSEUS Project:
Schmidt, D.C., 2006. Model-Driven Engineering. IEEE
Computer Society.
Shishkov, B., 2016. Foreword. In BMSD’16, 6th
International Symposium on Business Modeling and
Software Design. SCITEPRESS.
Shishkov, B., 2005. Software Specification Based on Re-
usable Business Components (PhD Thesis), TU Delft –
SIKS Publishing. Delft.
Shishkov, B., Dietz, J.L.G., Liu, K., 2006. Bridging the
Language-Action Perspective and Organizational
Semiotics in SDBC. In ICEIS’06, 8th International
Conference on Enterprise Information Systems.
Shishkov, B. and Janssen, M., 2016. Towards a Service-
Oriented Architecture for eVoting. In BMSD’16, 6th
International Symposium on Business Modeling and
Software Design. SCITEPRESS.
Van der Aalst, W., 2011. Process Mining - Discovery,
Conformance and Enhancement of Business Processes.
Springer-Verlag, Berlin Heidelberg.
Sixth International Symposium on Business Modeling and Software Design