On the Path Towards Standardisation of a Sensor API for Forensics

Investigations

Marco Manso

, Bárbara Guerra

, Fernando Freire

, Roberto Chirico

, Nicola Liberatore

René Linder

, Ulrike Schröder

and Yusuf Yilmaz

Particle Summary, Lda., Lisbon, Portugal

Diagnostic and Metrology Laboratory, ENEA C.R., Frascati, Italy

Research & Development, Consorzio C.R.E.O., L’Áquila, Italy

Standards Committee Medicine, German Institute for Standardization (DIN), Berlin, Germany

roberto.chirico@enea.it, nicola.liberatore@consorziocreo.it, rene.lindner@din.de, ulrike.schroeder@din.de,

Yusuf.Yilmaz@din.de

Keywords: Forensics Analysis, CBRNe, Sensors, API, Standardisation.

Abstract: Forensics investigations need to be conducted efficiently and accurately especially in situations where time is

a scarce resource. Novel technologies, like forensic sensors, can aid investigators in trace detection,

visualisation, identification and interpretation on site. Arising from the need to connect different sensors to a

remote digital management software, a network-enabled Sensor API is proposed to enable any compliant

CBRNe Sensor to connect and exchange information in a harmonised and interoperable way. As a result, a

Standardisation Workshop agreement, on CBRNe SENSOR API - Network Protocols, Data Formats and

Interfaces, was initiated to promote standardisation of the Sensor API. The new proposed standard will allow

sensor manufacturers to focus on sensor development work, benefitting from already defined interfaces and

data models. Moreover, forensic investigators, acting as end-users, can better understand and analyse (well

defined) sensor outputs, thus improving their work efficiency and facilitating technology acceptance.

1 INTRODUCTION

Crime scene investigation (CSI) involves careful and

thorough observation of crime scenes to identify and

collect forensics evidence potentially relevant to the

solution of the case. It is important that the

investigation is performed efficiently and accurately,

since it will allow directing subsequent law

enforcement actions towards well identified

individuals or groups, supported by the collected

evidence and under the rule of the law.

Over the years, CSI methods, technologies, tools

and procedures have greatly evolved, accompanying

scientific breakthroughs (e.g., DNA profiling),

paving the way for the creation of the forensic science

field. Technologies, in particular, have been

https://orcid.org/0000-0003-0953-049X

Traces are the most elementary information that result from crime. Traces [...] need to be detected, seen, and understood to

make reasonable inferences about criminal phenomena, investigation or demonstration for intelligence, investigation and

court purposes. (Margot, 2011)

developed to make the CSI process faster and safer

for investigators, without compromising reliability.

While investigators have tools to use on-site (e.g.,

multispectral cameras, 3D scanners, drug kit tests),

they still depend on laboratorial analysis, as the

“golden standard”, for classification and

identification of traces

(e.g., drug profiling,

fingerprint identification) and producing court

admissible evidence. Notwithstanding, the laboratory

analysis process may result in the destruction of the

sample and can be lengthy, usually taking several

hours or days. Time becomes a scarce resource,

especially in crime scenes where preserving traces is

challenging, such as outdoor environments or

hazardous environments, contaminated by dangerous

biological or chemical agents.

Manso, M., Guerra, B., Freire, F., Chirico, R., Liberatore, N., Linder, R., Schröder, U. and Yilmaz, Y.

On the Path Towards Standardisation of a Sensor API for Forensics Investigations.

DOI: 10.5220/0011688300003399

In Proceedings of the 12th International Conference on Sensor Networks (SENSORNETS 2023), pages 15-22

ISBN: 978-989-758-635-4; ISSN: 2184-4380

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

Figure 1: RISEN API: A modular approach to integrate sensor’s data.

Hence, the following features would represent a

significant step forward in forensics investigations

(Manso et al., 2020):

 Detect traces on-site as soon as possible (ideally

in near real-time), before they degrade and loose

forensic information relevant for criminal

investigation.

 Perform contactless detection and analysis of

various trace materials at the crime scene,

without risking compromising their integrity.

 Perform on-site classification

of a wide range

of traces, by exploiting finer compositional

differences to push levels of specificity and

discrimination toward the limits of within-

source variation, based on more analytical

information from the specimen itself and from a

more comprehensive and relevant body of

reference data.

In order to meet the above, several mobile analytical

instruments (herein also referred as sensors) that are

easily deployable or handheld have been developed,

providing novel capabilities in forensics

investigations. Being a novel field, the lack of

available standards results in manufacturers

following their own implementation path, which in

turn results in non-interoperable sensors that

negatively impact on the efficiency of what is by

nature an already time-consuming activity.

This paper introduces the work developed as part

of the European Action Real-tIme on-site forenSic

tracE qualificatioN (RISEN)

, with the support of the

German Institute for Standardization (DIN), in

identifying and promoting new standards in forensic

sciences, particularly, in the definition of a sensor

Application Programming Interface (API) enabling

different forensics sensors to communicate in a

consistent and harmonised way with a remote server,

using widely used web-based technologies.

Trace classification is based on a comparison between the

unknown specimen to be analysed and one reference

sample of known origin to infer if they belong to the same

class. (Champod, 2013)

The remainder paper is structured as follows:

Section 2 presents the RISEN project, being an

innovative approach for conducting on-site CSI based

on 3D scene reconstruction and use of interoperable

sensors for identification of traces; Section 3

describes the sensor API enabling sensor

interoperability, starting from the concept, followed

by core technologies, and sensor data model. The

section also presents possible deployment options,

enabled by the Sensor API, and preliminary results

attained in RISEN; Section 4 introduces the

standardisation efforts already initiated for the Sensor

API; Section 5 concludes this paper.

2 RISEN: ON-SITE SENSORS

SUPPORTING FORENSICS

INVESTIGATIONS

The RISEN project introduced an innovate concept in

forensic investigations in the context of CSI on sites

affected by chemical, biological or explosives attack.

Coordinated by the Agenzia Nazionale per le Nuove

Tecnologie, L'energia e lo Sviluppo Economico

Sostenibile (ENEA), the RISEN aim is to develop a

set of sensors for the optimisation of the trace

detection, visualisation, identification and

interpretation on site, with a consequent reduction of

the time and resources in the laboratory. RISEN

started in 2019 and is planned to be finalised in 2024.

In the RISEN project, several network-enabled

real-time contactless sensors for handling traces on-

site are being developed. Moreover, using

commercially available 3D scanning technologies,

RISEN is also allowing the generation of an accurate

3D recreation of the entire crime scene, integrating

information collected by sensors and providing an

immersive environment for investigators to evaluate

RISEN has received funding from the European Union’s

Horizon 2020 research and innovation programme under

grant agreement No 883116.

SENSORNETS 2023 - 12th International Conference on Sensor Networks

hypotheses and conduct highly detailed

investigations.

Table 1 presents the RISEN sensors together with

their respective application in forensics

investigations.

All sensors developed in RISEN are connected to

a server software system (i.e., the 3DA-CSI System)

that receives and manages data sent by sensors, via a

Digital Evidence Management component. Since its

inception, the concept of a modular network-enabled

approach that seamless connect the different RISEN

sensors was envisaged. This approach led to the

creation of the RISEN Sensor API, described next.

Table 1: List of RISEN sensors and their application in the

forensics field (Manso et al., 2020).

RISEN

Sensor

Application in Forensic Investigations

Chemical evidence

Biological evidence

and biological agents

GC-QEPAS

Sensor

Volatile and

semivolatile

constituents of

evidence.

BARDet -

BioAerosol

Detector

Any bioaerosol in the

air, which may pose a

threat to personnel at

the scene.

LS-LIF

Sensor

(1), (5)

Change of type of

material (example: IED

components, glasses,

etc.)

On solid targets:

Localization of

Explosives, gunshot

residues, body fluids,

etc.

Any trace material on

a solid surface

Raman Sensor

(1)

Drugs, explosives,

gunshot residues,

fibers, paints,

varnishes…

Body fluids: blood,

saliva, semen, sweat,

vaginal fluid.

Dating of blood

(possibly).

IR Sensor

(1)

Drugs, explosives,

gunshot residues,

fibers, paint, common

false positives during

blood residues (paint,

coffee, soda).

Body fluids: blood,

semen, vaginal fluid,

urine.

Dating of blood.

LIBS Sensor

(2)

Explosives, gunshot

residues, earth material,

glasses, paints

Presence (YES/NO)

of body fluids

IMS with

surface

desorption

capability

(3)

Traces of drugs,

explosives and

hazardous material

detection and

identification.

Volatile/Semivolatile

evidences material,

presented on scene of

crime, identification

ased on fingerprint.

Hyperspectral

imaging (HSI)

(1), (4)

Drugs, explosives.

Body fluids: blood,

semen, vaginal fluid,

urine.

Dating of blood.

(1) Non-destructive technique; (2) Micro-destructive technique (1μg

per analysis); (3) Non-destructive or micro-destructive technique

(nanograms); (4) UV-Vis range (400-1000nm), NIR range (1000-

2500nm); (5) LS: Laser Scattering, LIF: Laser Induced Fluorescence

3 RISEN SENSOR API

This section presents the concept behind the sensor

API, followed by the selected enabling technologies,

the sensor data model, deployment options allowed

by the API and preliminary results from a RISEN

sensor in using the API.

3.1 Concept

The RISEN Sensor API was implemented by

PARTICLE Summary to define a consistent and

harmonised way for sensors to connect and send

information to a server system. The Sensor API is

depicted in Fig. 1.

The sensor API concept includes a server-side

component and a client-side component. The client-

side component comprises a "Generic API" that

defines general functions to be supported by a RISEN

sensor, such as registration, connection, reporting

status and sending measurements. Sensor specific

functions can be implemented by extending the

"Generic API", while keeping compatibility with the

RISEN System.

The client-side component connects to the server-

side component that, via the “sensor interface bus”,

sends sensor data to the RISEN 3DA-CSI System.

The server-client connection supports Internet-

based technologies for maximum interoperability and

compatibility, including the use of the Internet

Protocol (IP) and the Transmission Control Protocol

(TCP)/User Datagram Protocol (UDP) for data

exchange, and is realised via wired (e.g., Unshield

Twisted Pair (UTP) or optical cable) or wireless (e.g.,

IEEE802.11ac/Wireless Fidelity (Wi-Fi))

connectivity. Clients can access the server API using

the server's Uniform Resource Identifier (URI).

3.2 Core Technologies: HTTP, JSON

and REST

The approach for the RISEN Sensor API is based on

open-source and widely used technologies and it

follows the REpresentational State Transfer (REST)

architecture. The client-side component can send

requests to the server-side component through the

server URI, using the Hypertext Transfer Protocol

(Secure) (HTTP(S)) protocol, including payload data

typically formatted as JavaScript Object Notation

(JSON), eXtensible Markup Language (XML) or

plain text. The API favours the use of JSON for

payload data.

On the Path Towards Standardisation of a Sensor API for Forensics Investigations

In RISEN, the HTTP protocol is used, including the

methods described below (as per RFC7231

 GET can be used to request transfer of a current

selected representation for the target resource. It

is the primary mechanism of information

retrieval.

 POST requests that the target resource processes

the representation enclosed in the request. It is

typically used as a mechanism to upload

information.

 PUT requests that the state of the target resource

be created or replaced with the state defined by the

representation enclosed in the request message

payload.

 DELETE requests that the origin server removes

the association between the target resource and its

current functionality.

Each HTTP request produces a status code indicating

if the request was successful or if an error occurred.

The status codes are categorised as follows:

 1xx (Informational): The request was received,

continuing process.

 2xx (Successful): The request was successfully

received, understood, and accepted.

 3xx (Redirection): Further action needs to be

taken in order to complete the request (i.e., the

operation should be retried).

 4xx (Client Error): The request contains bad

syntax or cannot be fulfilled (e.g., bad request or

unauthorised request).

 5xx (Server Error): The server failed to fulfil an

apparently valid request.

3.3 Message Broker for on-Event

Processing

The publish-subscribe paradigm enables on-event

processing as a result of its capability to push

messages to clients, meeting known criteria. The

publish-subscribe paradigm implies the existence of

different roles:

 a publisher, which produces messages,

 a subscriber, which consumes messages, and

 a message broker, which gathers and distributes

the messages from publishers to subscribers.

The protocol is well suited to disseminate sensor

information, so it is a widely-used protocol in

network-enabled environments. Within the RISEN

Sensor API, the publish-subscribe paradigm

complements the REST architecture in the sense that

the latter is reactive (responds to the client or server

requests) while the former is proactive (on event,

notifies subscribers of new messages).

https://tools.ietf.org/html/rfc7231

The lightweight Message Queuing Telemetry

Transport (MQTT), standardised as ISO/IEC PRF

20922 (ISO, 2016), was selected as the message

broker for the Sensor API.

3.4 Sensor Data Model

The RISEN Sensor API also defines the necessary

data models used in information exchange. The data

model includes the “Sensor” group that contains

entities representing sensors and sensor-generated

data. The sensor entity together with other relevant

entities are presented in Fig. 2.

A sensor is represented in the “Sensor” entity.

The "SensorEvent" entity represents the basic

information structure related to dynamic sensor data.

It is extended by: “SensorStatusEvent” entity, that

refers to sensor status information, usually

operational status and battery level; and

“BaseMeasurementEvent” that includes the various

supported sensor measurements (e.g., detection,

category, timeseries data). Thus, two entities, with

several sub-entities associated, "extend" the

SensorEvent, inheriting its fields and adding new

ones to address needed specificities. Thus, a sensor

can generate multiple SensorEvents.

3.5 Deployment Options

The network-enabled architecture selected for the

RISEN System and the Sensor API, supported by

widely adopted and open web-standards, delivers a

high degree of flexibility concerning the deployment

options for the RISEN System in operational

environments.

This subsection presents the deployment options

for the RISEN System, allowing to meet most end-

user scenarios.

3.5.1 RISEN Deployment at the Crime

Scene

In this setting, the RISEN System is transported and

installed at the crime scene. This includes all RISEN

sensors and the 3DA-CSI System. A local network

(wired or wireless) is established to connect all

RISEN modules. The RISEN sensors send

measurements to the 3DA-CSI System. The

investigator accesses the 3DA-CSI System locally,

using a computer or a mobile App. All information is

locally stored in the 3DA-CSI System.

SENSORNETS 2023 - 12th International Conference on Sensor Networks

Figure 2: Sensor data model (preliminary).

In this setting, illustrated in Fig. 3, it is not

possible to remotely access information from the

3DA-CSI System (e.g., request assessment from an

expert not located at the crime site). Users can export

all gathered data to a central 3DA-CSI System a

posteriori, using the RISEN 3DA-CSI System’s

export/import functions. It is advantageous for

situations where network connectivity with a central

3DA-CSI System is not possible (or desired).

However, the setting also limits the availability of

gathered data in near-real time to investigators on-site

only. Moreover, the 3DA-CSI System should be

running on a portable device, with limited processing

capabilities.

Figure 3: Local Deployment.

On the Path Towards Standardisation of a Sensor API for Forensics Investigations

3.5.2 RISEN Deployed in a Vehicle near the

Crime Scene

In this setting, illustrated in Fig. 4, the RISEN System

is transported and installed at the crime scene.

However, while the RISEN sensors are placed at the

crime scene, the 3DA-CSI System remains in a

vehicle, stationed near the crime site, thus delivering

good processing and power capabilities.

Figure 4: Deployment in Vehicle.

A local wireless network is established to connect

all RISEN modules. Where needed, network

repeaters are installed to ensure adequate network

coverage. The RISEN sensors send measurements to

the 3DA-CSI System. The investigator accesses the

3DA-CSI System at the crime site using a computer

in the vehicle or, via a portable computer or App, at

the crime scene. All information is locally stored in

the 3DA-CSI System.

This setting is very similar to the previous one and

presents as main advantage the increased computing

and power capabilities provided by the infrastructure

in the vehicle.

3.5.3 Cloud Deployment

This setting, illustrated in Fig. 5, is advantageous for

situations where network connectivity with a central

3DA-CSI System is possible and desired. It also takes

advantage of advanced computing capabilities

provided by a stable infrastructure. However, it

requires continuous network connectivity, a

requirement that is not present in all crime scenes.

Moreover, security concerns might arise concerning

assurance of data confidentiality. The fact that the

3DA-CSI System is accessible over the Internet (even

via a VPN) may bring additional security risks that

might not be acceptable by law enforcement agencies

(LEAs).

Figure 5: Cloud Deployment.

This setting is advantageous for situations where

network connectivity with a central 3DA-CSI System

is possible and desired. It also takes advantage of

advanced computing capabilities provided by a stable

infrastructure. However, it requires continuous

network connectivity, a requirement that is not

present in all crime scenes. Moreover, security

concerns might arise concerning assurance of data

confidentiality. The fact that the 3DA-CSI System is

accessible over the Internet (even via a VPN) may

bring additional security risks that might not be

acceptable by the LEAs.

3.6 Preliminary Results

RISEN provides a suitable environment for creating

and demonstrating the capabilities of a Sensor API

capable to seamlessly connect various specialised

sensors used for forensic investigations.

The Sensor API was first tested using the GC-

QEPAS sensor developed by CREO. GC-QEPAS is

the acronym of Gas Chromatography Quartz

Enhanced PhotoAcoustic Spectroscopy, which is one

of the several techniques of spectroscopy allowing

unambiguous detection and identification of gases

and vapours by means of the measurement of their

absorption band/peaks. The GC-QEPAS sensor is

primarily intended for protection of operators against

health and safety hazards (mainly toxic vapours and

chemical warfare agents (CWAs)) while entering the

crime scene. Moreover, the sensor can be used to

identify volatiles evaporating from liquid/solid traces

present at the crime scene (Viola et al., 2019).

The GC-QEPAS demonstrated the Sensor API

capability to communicate over a secure connection

(HTTP over TLS), authenticate the sensor (use sensor

credentials to perform operations), register the sensor,

and receive sensor measurements in different

formats: detection list, measurement spectra and

SENSORNETS 2023 - 12th International Conference on Sensor Networks

pictures. Examples of received GC-QEPAS sensor

data are presented in Fig. 6, 7 and 8.

Figure 6: GC-QEPAS detection list: ACETONE and

ALCOHOL substances, including their probability.

Figure 7: GC-QEPAS generated spectrum associated with

different substances (DMMP, DPGME, SAFROLE and

METHYL SALICYLATE).

Figure 8: GC-QEPAS sent picture related with a performed

measurement.

4 STANDARDISATION

The RISEN project is developing a generic Sensor

API that can be used by different RISEN sensors

manufactured by different organisations. The Sensor

API can be further generalised, allowing any CBRNe

Sensor to connect and exchange information, in a

network-enabled environment, with remote services

in a uniform way.

Coordinated by DIN, a dedicated Committee for

Standardization (CEN) Workshop Agreement

(CWA) on CBRNe SENSOR API - Network

Protocols, Data Formats and Interfaces (DIN, 2022)

has been proposed with the following reasons in

mind:

 Facilitate analyst data interpretation by using

familiar, well-defined and consistent sensor data

formats;

 Enable evidence management information

systems to receive data from compliant CBRNe

sensors without requiring custom

developments;

 Include 3D-spatial support in sensor data,

enabling 3D data location;

 Improve operational autonomy and efficiency

with digitalisation of traces and evidences;

 Enable forensics data sharing between

practitioners.

This proposed standard has relation with the

following:

 ISO 21043:2018, Forensic Sciences parts 1 to 5

(ISO, 2018);

 ISO/IEC 30128, Information technology —

Sensor networks — Generic Sensor Network

Application Interface (ISO, 2014);

 ISO/IEC series 29182, Information technology

— Sensor networks: Sensor Network Reference

Architecture (SNRA) (ISO, 2013).

The CWA kick-off meeting was held on 10 October

2022, in Jurmala (Latvia), as part of the RISEN

plenary meeting. This workshop is to be followed by

additional four Workshop meetings and web

conferences, allowing comments and suggestions to

be submitted for supporting standardisation.

5 CONCLUSION

RISEN introduced an innovative concept in forensic

investigations by developing and connecting a set of

sensors for handling traces on site, thus optimising

trace, detection, visualisation, identification and

interpretation on site, with a consequent reduction of

the time and resources consumed by laboratory

analyses.

Resulting from a need to connect different sensors

to a remote server, the concept of a modular network-

enabled approach, was envisaged. This approach

On the Path Towards Standardisation of a Sensor API for Forensics Investigations

resulted in the RISEN Sensor API. With

interoperability and scalability as key goals, the

Sensor API was implemented considering open-

source and widely used technologies, including the

REST architecture, HTTP(s), TCP/IP, JSON and

MQTT.

The Sensor API was tested subsequently, using

the GC-QEPAS sensor, and successfully

demonstrated the capability to register the sensor and

receive its measurements in different formats. It was

also validated the Sensor API’s capability to be

further generalised, thus allowing any CBRNe Sensor

to connect and exchange information, in a network-

enabled environment, with remote services in a

uniform way.

Under the leadership of DIN, a CWA was

promptly initiated to promote standardisation of the

Sensor API. The new CWA aims to define the API

for CBRNe sensors, enabling specialised IT system

manufacturers to provide innovative solutions

(beyond sensor scope) atop of well-known interfaces

and data models. At the same time, CBRNe sensor

manufacturers can focus on sensor development

work, benefitting from already defined interfaces and

data models. Finally, forensic investigator end-users

can better understand and analyse (well defined)

sensors outputs, thus improving their work efficiency

and promoting technology acceptance.

ACKNOWLEDGEMENTS

The RISEN project has received funding from the

European Union’s Horizon 2020 research and

innovation programme under grant agreement No

883116.

RISEN public information can be assessed at the

project website https://www.risen-h2020.eu/.

REFERENCES

Champod C. (2013) Overview and meaning of

identification/individualization. In: Siegel JA and

Saukko PJ (eds) Encyclopedia of Forensic Sciences.

Waltham: Academic Press, 303-309.

DIN (2022). CEN Workshop on ‘CBRNe SENSOR API

Network Protocols, Data Formats and Interfaces’.

Online article. Published at: 2022-09-08. Available at:

https://www.cencenelec.eu/news-and-

events/news/2022/workshop/2022-09-08-sensor/

ISO. (2013) ISO/IEC 29182-1:2013. Information

technology — Sensor networks: Sensor Network

Reference Architecture (SNRA) — Part 1: General

overview and requirements. Edition 1. Technical

Committee: ISO/IEC JTC 1/SC 41 Internet of things

and digital twin. Publication date: 2013-06.

ISO. (2014) ISO/IEC 30128:2014. Information technology

— Sensor networks — Generic Sensor Network

Application Interface. Edition 1. Technical Committee:

ISO/IEC JTC 1/SC 41 Internet of things and digital

twin. Publication date: 2014-11.

ISO. (2016) ISO/IEC 20922:2016. Information technology

— Message Queuing Telemetry Transport (MQTT)

v3.1.1. Edition 1. Technical Committee: ISO/IEC JTC

1 Information technology. Publication date: 2016-06.

ISO. (2018) ISO series 21043:2018. Forensic sciences.

Edition 1. Technical Committee: ISO/TC 272 Forensic

sciences. Publication date: 2018-08.

Margot, P. (2011) Forensic science on trial - What is the

law of the land? Australian Journal of Forensic

Sciences. 43:2-3, 89-103.

Manso, Marco; Chirico, Roberto; Peltola, Johannes;

Engström, Philip; Larsson, Håkan; Berggren, Jimmy.

(2020) The RISEN Project – A Novel Concept for Real-

time on-site Forensic Trace Qualification. International

Command and Control Research and Technology

Symposium (ICCRTS). 25th ICCRTS Proceedings.

https://doi.org/10.5281/zenodo.4264926

Viola, R., S. Mengali, N. Libetatore, S. Zampolli, I. Elmi

and F. Mancarella. (2019) Deployable Sensor for Trace

Identification of Hazardous Chemicals in Dirty

Environment, Based on FAST Gas-chromatography

and Quartz Enhanced Photoacoustic Spectroscopy.

2019 PhotonIcs & Electromagnetics Research

Symposium – Spring (PIERS-Spring), Rome, Italy,

2019, pp. 223-228. (DOI:10.1109/PIERS-

Spring46901.2019.9017698)

SENSORNETS 2023 - 12th International Conference on Sensor Networks