1 Introduction

Service systems can be defined as dynamic value-cocreation configurations of resources, connected internally and externally to other service systems by value propositions (Maglio et al., 2009). This configuration includes in general people, organizations, shared information and technology. Service consumers and providers interact by creating value in the form of a value proposition, which is an invitation from actors to one another to engage in service (Chandler & Lusch, 2015). The combination of these concepts with advances and developments in information technology (IT) results in the emergence of smart service systems (SSS), which are software systems capable of learning, dynamic adaptation, and decision making based upon received and transmitted data (Lim & Maglio, 2018). In general, smart service systems are capable of monitoring, optimizing and controlling smart products and devices to deliver value for the service participants. In the smart city context, smart service systems enable value-cocreation for the participants of the smart city ecosystem to address its main challenges (like urbanization, climate change, sustainable transport, housing, and healthcare) by an intelligent use of information technologies (Wolff et al., 2020). One of the main challenges to deliver these goals is an efficient way of engineering smart service systems to enable the city and its citizens to harness the large volumes of data that are produced by sensors and digital infrastructure to improve sustanability by service innovation (Dobler et al., 2021; Suzic et al., 2022). In this paper, we address this software engineering challenge by proposing a low-coding approach based on a domain-specific modeling language that we call Smart Service Definition Language (SSDL). The basic goal of this language is to provide a means of defining, sharing and deploying smart service systems in a natural way also for non-technical users, enabling the relevant stakeholders in the city administration to autonomously define and deploy smart service systems based on their needs and the available infrastructure. SSDL is the foundation for a low-coding platform capable of generating applications based on a simple formal description, largely simplifying the development of smart services in practice.

This paper is organized as follows. In Sect. 2 we begin by providing a review of related work in the field of smart systems design with a focus on smart cities. Section 3 outlines the research and design methodology used and provides the syntax and semantics definitions for SSDL. In Sect. 4 we describe a general software architecture for implementing a low-coding platform for smart service systems based on SSDL. Our approach is evaluated in Sect. 5 by applying it to an example use case. We conclude in Sect. 6 with a summary.

2 Related work

Smart products integrate resources and activities of service providers and service consumers, which allows them to adapt the service systems based on contextual data (Beverungen et al., 2019a). In Beverungen et al. (2019b), the authors present the concept of smart services and smart service systems. As smart products are widely used for smart sevices in smart cities the related work helps us better understand our target domain. Jussen et al. (2019) present a service-engineering approach for smart services and illustrates its successful application and its impact on a medium-sized company. The study focuses on the development steps involved and the interaction and interconnection of elements in smart services. Komninos et al. (2016) propose an ontology for smart cities called Smart City Ontology (SCO) and present its building blocks (e.g., technology, structure, functions, design), and properties for connecting those blocks in the ontology. This study was enhanced in Komninos et al. (2021) with an OWL ontology. In this work, we use this OWL-based Smart City Ontology to provide the language with semantic and syntactic features related to smart cities, therefore these related works help us to understand the smart city landscape, identify its main components and the processes involved in smart city applications. In Huber et al. (2019) the authors develop a domain-specific modeling language for smart service systems and demonstrate it by presenting real-world scenarios. This work focuses on concepts of domain-specific modeling and relationships in smart service system domains, highlighting the importance of developing domain-specific modeling languages for better coverage of the target domain. Similarly, guidelines for selecting an appropriate metamodeling language are presented in Frank (2013). The authors demonstrate a process for specifying a domain-specfic modeling language based on requirements analysis. We considered this work as our starting point for designing our domain-specific modeling language.

3 Smart Service Definition Language

SSDL is a text-based language. An SSDL file contains the definition of a smart service. For the general structure, we borrowed some syntactic elements from YAML,Footnote 1 as this language provides syntactic constructions that can be regarded as near to natural language. We then enriched these constructions by defining additional semantic elements from the Smart City Ontology. We followed the general methodology for designing domain-specific modeling languages proposed in Frank (2013). This methodology comprises the following steps: (1) clarification of scope and purpose, (2) analysis of generic and specific requirements, (3) language specification, (4) design of graphical notation, (5) development of a modeling tool, and (6) evaluation and refinement.

Table 1 shows a summary of the syntax of SSDL. The preamble contains metadata, i.e. general data about the smart service itself, mainly for documentation purposes. Two metadata-fields are mandatory: name and version. Additional metadata-fields can be used to define the general area that the smart service belongs to, like environment or transportation.

Table 1 Structure of the Smart Service Definition Language (SSDL)
Full size table

The data section contains definitions regarding the data sources used, which typically belong to the sensor infrastructure already deployed in the smart city. In this section, one or more data sources can be defined using a YAML-like list notation. The data sources themselves can be specified using the following properties: the name of the data source, the type of the data source used and the name of the Internet-of-Things (IoT) provider (e.g. FiwareFootnote 2). Compound objects are used to specify additional details: format specifies the data returned by the data source, including property names and types, config describes how to authenticate against the IoT platform, and queries defines how to query specific sensors or entities.

The application section contains the declarations needed for specifying the smart service itself. This includes properties like the type of the application and how to display data. The properties that can be specified are: the type of the application, which will be a web application by default, the layout (like single-page or other types of layouts), the standard user roles, like administrator and a read-only user type, and the data visualization used, like several types of plots or tables.

The deployment section is optional and specifies deployment environments where the smart service will be published and made available to the end users. A deployment environment is a runtime or framework being executed on the server that runs the smart service system. By defining the runtime environment in the SSDL file, the user can use tools for automating the deployment process and thus decrease time-to-market as much as possible.

4 Architecture

In this section, we outline a general software architecture for a low-coding platform based on SSDL. An overview of this architecture is given in Fig. 1. We begin with the user interface (UI) component at the bottom, which enables the user to interact with the system. The central element of the UI is a text editor featuring syntax highlighting (rendering language keywords and symbols differently) and validation (providing visual cues like underlining incorrect syntax and explanations in text form).

Low-coding features like pre-defined blocks of code that can be dragged directly into the editor are also integrated in the UI. For instance the user can choose from a sidebar between different pre-defined components like default data blocks (data section), default application (web applications) and deployment types (container-based deployment). The configuration of these blocks is done visually by means of configuration dialogs that can be used to save the configuration or modify it later.

Fig. 1
An architectural diagram of a low-coding platform. It includes a backend, which consists of language, data, and application services. The application services interact with the web front and provide data to the cloud provider and image repository.

An architectural overview for a low-code platform based on SSDL

Full size image

The backend is organized as a service-oriented architecture (SOA) composed of several independent services, each providing a subset of the needed functionality. The main services composing the backend are the ApplicationService, the LanguageService and the DataService. The ApplicationService is the central business logic service for the web application that communicates with the frontend to provide the requested functionality. Its main task is to serve as a controller for the features supported by the UI and a proxy to the other services by exposing the necessary APIs. The LanguageService implements a compiler for SSDL and generates the source code of the corresponding smart service (which we call the artifact). This service is also responsible for handling validation requests from the UI, which are forwarded by the ApplicationService. The output of the LanguageService is a fully fledged web application based on a general programming language (like Java or Python). The compiler generates the code of the application based on templates, which are in essence source files with placeholders that are filled at compile time. These templates can be either general (concerned with the general structure of the application and the main business logic) or IoT-specific, providing modules implementing API clients for the target IoT platform. For instance, if the sensor layer is based on the Fiware framework, the template that implements the Fiware API is selected by the compiler. The implementation is assembled in compile time with the smart service so that the service, when deployed, can access and fetch data from the corresponding sensor layer. This encapsulates the concrete data modeling for a specific IoT vendor and makes SSDL independent of the specific IoT platform used. Finally, the DataService is responsible for managing a repository of source SSDL files. These files are kept in a data store. Additionally, this services manages all the other types of data needed by the application, like user data.

5 Evaluation

We now present a use-case solved using the proposed domain-specific language in the smart city context: smart parking. The problem of managing the available parking space in modern cities has practical importance for both the drivers and the operators and has sustanability implications. There are several specific variants of this problem depending on the goals and the technology used (Al-Turjman & Malekloo, 2019). In general, smart parking services alleviate congestion in city centres and thus reduce vacant slot search time which also results in reduced air pollution. The sensing layer consists in sensors placed in the available parking space so that the presence or absence of a vehicle can be measured. The sensors then transmit measurements using the corresponding network infrastructure to the IoT middleware. In a traditional smart service engineering approach, dedicated application development would be needed to build a tightly coupled application that communicates with the IoT middleware to fetch data and implement some functionality related to the data. In contrast to this approach, we now build an SSDL smart service definition in Fig. 2. In this definition, sensors of infrared type and four data fields of interest are specified: an identifier for the sensor making the measurement, the timestamp of the measurement, a boolean indicating if the parking slot is vacant or not, and the location of the parking slot. When compiled, this section would generate an implementation of the NGSIv2 REST API.Footnote 3 Next, the application is defined as a single-page web application with standard administrator and user roles. The application shows the data in two ways: first, it displays a map showing the city centre within a radius of 10 km where the data points are defined by their GPS coordinates and the boolean indicating if the spot is vacant or not. Additionally, it shows the data as a table. Note that all that we need is to specify a few lines of text instead of writing a full web application from scratch. This lowers the costs of developing such an application and at the same time serves as an implementation guide for further smart cities interested in introducing smart parking solutions themselves.

Fig. 2
A syntax summary of the smart parking service S S D L file. It includes various elements, such as name, version, domain, field, type, provider, configuration, query, sensor, roles, visualization, and files under the service, data, application, and deployment sections.

Example SSDL file for a smart parking service

Full size image

6 Conclusions and Future Work

In this paper, we presented a new domain-specific modeling language and a general software architecture for implementing a low-coding approach for developing smart services in the smart city context. The main contributions of the present study are the following: first, a general and flexible declarative formal language for automatically generating smart service applications was proposed. This language is designed by using a principled methodology and resembles natural language to booster acceptance by non-technical users. Second, SSDL represents the foundation for a low-coding platform for engineering smart services, allowing for implementing a wide variety of features for supporting the user (e.g. graphical modeling tools). Third, our approach is IoT platform agnostic, which means that it can work with arbitrary data models and middlewares. Adaptation to new platforms can be done by implementing an abstract layer that supports the corresponding middleware API.

Current ongoing work includes the implementation of a platform prototype to demonstrate its feasibility. Visualization features (like representing code blocks to be used graphically, and using drag-and-drop for connecting these components) should be investigated to determine their viability as well. The prototype will be further developed to implement an example use case from end to end, providing a sample implementation for first production usages.