QR Codes: From a Survey of the State of the Art to Executable eQR Codes for the Internet of Things

QR codes are increasingly used in a plurality of scenarios, and research activities are being successfully carried out to improve this technology and widen its contexts of applicability. After an extensive survey of the state of the art on the subject, this work presents the new, promising possibility to embed a programming language in a QR code. This new kind of executable QR codes, we named eQR codes, enable interaction with end users even in the absence of an Internet connection, and provide a sort of Internet of Things paradigm where intelligence is embedded in the object tag in the form of a program. Among all the possible languages that can be embedded, this work focuses on a powerful but compact (in terms of QR code storage occupation) dialect, termed QRtree, which is aimed at implementing decision trees. The eQR code technology makes a new class of applications possible, e.g., providing hints for navigation or instructions for using rescue devices in places with no network coverage like mountains and caves. Smart interactive user manuals are enabled as well. Besides defining the QRtree language and eQR code structure, this article describes all the steps needed to generate eQR codes and to manage their execution in end-user devices. A simple yet realistic example and the related code are also presented, to practically show how this technology can be used to solve real-world problems. For the example, the QRtree version of the code takes 234B, less than one-half the size of an equivalent program in Python bytecode (634B).

Abstract-QR codes are increasingly used in a plurality of scenarios, and research activities are being successfully carried out to improve this technology and widen its contexts of applicability.After an extensive survey of the state of the art on the subject, this work presents the new, promising possibility to embed a programming language in a QR code.This new kind of executable QR codes, we named eQR codes, enable interaction with end users even in the absence of an Internet connection, and provide a sort of Internet of Things paradigm where intelligence is embedded in the object tag in the form of a program.Among all the possible languages that can be embedded, this work focuses on a powerful but compact (in terms of QR code storage occupation) dialect, termed QRtree, which is aimed at implementing decision trees.The eQR code technology makes a new class of applications possible, e.g., providing hints for navigation or instructions for using rescue devices in places with no network coverage like mountains and caves.Smart interactive user manuals are enabled as well.Besides defining the QRtree language and eQR code structure, this article describes all the steps needed to generate eQR codes and to manage their execution in end-user devices.A simple yet realistic example and the related code are also presented, to practically show how this technology can be used to solve real-world problems.For the example, the QRtree version of the code takes 234B, less than one-half the size of an equivalent program in Python bytecode (634B).Index Terms-Compilers, decision trees, executable QR (eQR) code, programmable QR code, QR code.

I. INTRODUCTION
T HE TECHNOLOGY behind the popular 2-D barcodes known as QR codes is now three decades old [1].Nevertheless, it is still experiencing an endless spring due to the countless application contexts where it can be profitably applied.Popular examples include marketing [2], authentication [3], security [4], augmented reality [5], and transportation [6], to cite a few.Similarly to radio-frequency identification (RFID) [7], which constitutes one of the earliest enabling technologies for the Internet of Things (IoT), QR codes allow the quick identification of real-world objects, permitting them to be directly mapped in the cyberspace and "accessed" through the Internet.Typically, QR codes contain data that can be interpreted by an application: either numeric references, which have a similar function as linear barcodes (e.g., identifying or characterizing a particular object), or network references in the form, for instance, of a uniform resource locator (URL) that directly points to remote network resources.In the former case, a network query is typically needed to retrieve the information associated with the object (unless it is stored in the device's memory), while in the latter, accessing the relevant URL mandates that the device used for reading the QR code (e.g., a smartphone) is connected to a network (either the Internet or, at least, a local Intranet).
Many research activities have been conducted in the past decades on QR codes, and the first contribution of this work is to provide a concise but comprehensive survey of the state of the art about the latest innovations in this sector.The second, innovative contribution is to present a new type of QR code (also known as sQRy), we named executable QR (eQR) code, which enables interaction with the user by directly embedding a runnable program.The ability to include algorithms that can be executed locally is what differentiates eQR technology from traditional QR codes.This idea was preliminarily proposed in [8], which, to the best of our knowledge, is the only scientific work dealing with such a possibility at the time of writing.Basically, all devices that can be used for reading QR codes also work with eQR codes.Besides a camera with adequate resolution, local computation resources are needed to execute the embedded program.However, since this code is small by necessity, most existing smartphones likely meet these requirements.
Conventional QR codes already support interactivity.To this aim, a URL must be encoded that points to a suitable resource located on a Web server-either an HTML page that embeds client-side scripts or a server-side program to be executed remotely.However, doing so requires a properly working network connection.Although users nowadays expect to be provided all-time with ubiquitous Internet connectivity, this is unfortunately not always the case.Many places still exist, even in modern towns, where decent connectivity is often unavailable, e.g., basements, old buildings, and also very crowded rooms.By exploiting eQR codes, the user retains the ability to interact with "dumb" physical objects, but no Internet connection is demanded as the algorithm is stored in the payload of the QR code.This makes the eQR technology a nice addition to the IoT paradigm, and enables a whole range of functions that otherwise could not be implemented with conventional QR codes.For short, it provides users a "quasi-IoT experience" in the absence of Internet.One of the main problems of directly encoding programs in QR codes is their capacity.In fact, in the current version, they can store 2953 bytes at most.For this reason, the primary goal of our work is to define a suitable representation of programs (and the related translation process) to keep code footprint as compact as possible.The first method to limit the size of the generated QR code is to pose some constraints on the programming languages that can be encoded within it.
The eQR code format and content are based on the QRscript language, which permits to embed a variety of programming sublanguages (termed dialects).To this purpose, a header is included in QRscript to select the specific dialect encoded within the eQR code.
Besides dialect selection, this work also presents a specific language, we named QRtree, which has excellent characteristics from the point of view of compactness.Although the QRtree dialect only permits the implementation of decision trees, it suits a large number of scenarios derived from real needs.More specifically, this dialect permits defining programs that, by interacting with the user through a series of questions, select a specific leaf of the tree that represents the final advice.The root of the tree corresponds to the first question, and subsequent questions permit navigating the tree structure until a leaf is eventually reached.
To understand the real potential of eQR codes one must remember once again that, although we are living in a connected world, stable Internet connectivity is not always available everywhere and to everyone.If the QR code is located in a place without Internet access, QRscript and, in particular, the QRtree dialect could be a valuable enabler in many application contexts.A first, concrete example, which will be employed in the following to illustrate the benefits provided by our technology, are mountain trails, where eQR codes can be placed close to the forks and in some specific positions along the route to enable hikers to understand which is the best path to follow.The program included in the eQR code asks the user a number of questions to guide her/him in performing the most suitable choice based on aspects like her/his tiredness, available time, and personal preferences.
A second example, which has to do with guided diagnostics and maintenance, are boats: if a failure (e.g., broken engine) is experienced in a place with no network coverage (e.g., in the middle of the sea), running the program embedded in an eQR code (attached, e.g., to the engine itself) could help solving the problem, either directly (through explicit instructions) or indirectly (by providing references to the pages in the instruction manual where a solution can be found).Generally speaking, any book can be made "smart" by including an eQR code at its beginning, near to the index.Doing so allows readers to interact with the book using their smartphone, e.g., to quickly jump to the desired page/section.Not relying on the Internet, in this case, ensures complete privacy when looking for specific topics.
Besides entertainment and education, eQR codes can be targeted to more serious (and potentially critical) applications, e.g., to help people to operate medical instrumentation and rescue devices like defibrillators in emergency conditions, even in contexts where there is (temporarily) no network connection.Petrochemical plants, installations in desert areas, high mountains, forests, and many other similar scenarios can take advantage of the eQR code technology.
The organization of this article has the following structure.Section II describes the existing QR code technology and analyzes the state of the art.Section III introduces the new eQR code technology and the QRscript programming language it embeds.Section IV explains the QRtree dialect, while a real example of the steps needed to generate an eQR code and to execute it is shown in Section V. Finally, Section VI draws some final remarks.

II. QR CODES
Conventional QR codes, also known as quick response codes, are a 2-D barcode technology invented quite a long time ago (in 1994) by the Denso Wave Automotive company to track vehicles during manufacturing.The most recent version of the standard dates back to 2015 [9].QR codes improve over previous-generation 1-D barcodes by increasing recognition speed and storage capacity.

A. Technology
The main idea behind QR codes is to encode information on a printable support, customarily in the form of a grid of black and white square dots (see Fig. 1), which can be easily read by the camera of widespread commercial devices like smartphones and tablets.The information contained in the QR code is then extracted from the acquired image and converted into a binary representation.As depicted in the figure, specific finder patterns and alignment patterns are included that the reading device software exploits to identify the orientation and the position of the QR code within the captured image.
This approach can be used to encode various types of information like text, URLs, Wi-Fi network information, etc., by storing four types of data: 1) numeric; 2) alphanumeric; 3) binary; and 4) kanji.The latter is intended for encoding Japanese symbols.The maximum amount of information that can be stored in the QR code is related to the selected data Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
type.For eQR codes, numeric or binary codings were chosen to store the compiled QRscript program as a sequence of bits.In the case of numeric coding, the sequence of bits is interpreted as a base-10 number.
A concept of version is defined for QR codes to specify their size, in the range from 1 (21 × 21 matrix) up to 40 (177 × 177 matrix).For every version, four correction levels are possible: L (low), M (medium), Q (quartile), and H (high).They can be used to increase the overall robustness at the expense of the storage capacity.Version 40, with a low error correction level, is the combination that maximizes the storage capacity, that in this configuration is equal to 2953 bytes for binary coding and 7089 digits for numeric coding.By setting the appropriate version and correction level, a compromise between storage capacity and correction capability can be reached, depending on the characteristics of the application.

B. State of the Art
For the analysis of the state of the art, all the journal papers that contain the string "QR code" or "QR codes" in the title and that were published in the past five years (between 2019 and April 2023) by the main publishers, including IEEE, Elsevier, Springer, Wiley, and MDPI, were analyzed, for a total of 115 papers.Then, we selected a subset including some of the most representative works, divided in turn between those focused on application contexts (26 papers) and those related to research trends (29 papers).Within each category, the main areas of interest/topics were identified.
1) Application Contexts: QR code technology has been successfully applied in a variety of application contexts, including anti-counterfeiting, augmented reality, automatic configuration, fast reading, identification, localization, maintenance, medical, payment, recycling, safety, security, teaching, traceability, and tourism.This wide range of applications demonstrates that, nowadays, QR code usage embraces many different fields, making this technology increasingly pervasive both in daily use and in specialized contexts.
Selected works are summarized in Table I where, for every application context, the related papers are listed.For each paper, a brief description is also provided.
2) Research Trends: Besides applications, intense research activity is currently ongoing aimed at improving the QR code technology.Table II reports a selection of research trends organized by the main topics.Starting from the end of the table, security is the topic with the largest number of contributions.Its main purpose is to make this technology more secure, for instance by embedding additional and possibly hidden information within the QR code.Research identified with the topic printing type is related to the use of special inks or to the printing of QR codes on unusual surfaces.The insertion of multiple information in the same QR code and techniques to increase capacity are the two sides of the same coin, and they are aimed to increase the amount of information that can be packed in a conventional QR code.The proposal and experimentation of new techniques to improve recognition quality is the typical research activity that aims to enhance the usability of this technology.Anti-counterfeiting and improve other technologies are other specific research activities pertaining to QR codes.Instead, improve beauty is a relevant research topic aimed at embedding QR codes in other pictures in order to make them more beautiful and hence more suitable to be adopted, for example, for advertising purposes.The work about eQR codes presented here, as well as in [8], belongs to the category of the new research trends.They have been categorized under the programmability topic because they are aimed at defining the best ways to make QR codes executable.

III. QRSCRIPT AND EQR CODES
An eQR code is a QR code that embeds a specific programming language denoted QRscript.

A. Generation and Execution Chain
Fig. 2 highlights the steps involved in the generation of an eQR code (on the top) and its subsequent execution on the end-user device (on the bottom).
The steps of the generation chain are typically performed by the developer of the application (a company, an association, an individual, etc.) and lead to the creation of the eQR code, which can be printed, painted, displayed, or visualized in some way to the end user.The first step of this chain (arrow ①) is the translation from a high-level representation (e.g., programming language or graphical representation) to an intermediate representation.Although a small illustrative example is provided in Section V, this translation step is out of the scope of this work, because complete control on the selection of the high-level representation must be provided to the user, to the point that the program could be written using the intermediate language representation directly.In other words, a potentially large number of highlevel representations can be mapped to the same intermediate code.In the second generation step, which is represented by arrow ②, the intermediate representation is mapped to a binary In the inverse direction, denoted the execution chain, an eQR code that is visualized in some way to the end user (e.g., printed on posters or stickers, possibly with additional information) is translated to a binary representation (arrow ④).The application executing on the end-user device (e.g., a smartphone) has to recognize and extract the eQR/QR code contained in a digital image (e.g., acquired using the camera of the smartphone), perform the related error correction algorithms, and obtain the sequence of bytes representing the eQRbytecode.Again, many libraries are currently available to perform this step.The eQRbytecode is then translated into an intermediate representation (arrow ⑤) and, finally, the intermediate representation is executed by an application (a sort of virtual machine) running in the end-user device (arrow ⑥).While running the encoded program, this virtual machine interacts with the end user through an input/output interface (e.g., the touch screen of the smartphone).This part of the translation chain is not analyzed in detail in this work, because the implementation of the user interface and the characteristics of the virtual machine strongly depend on the needs of both end users and the application developer.The QRscript programming language specification only concerns the translation processes from the intermediate representation to eQRbytecode (arrow ②) and vice versa (arrow ⑤).

B. QRscript and eQR Codes Specification
The QRscript header is the first part of the eQRbytecode and specifies how to interpret the following part of the eQR code (Fig. 3).It is composed of five elements: 1) padding; 2) continuation; 3) security; 4) URL; and 5) dialect.The QRscript header is directly followed by the dialect code, which represents the encoded program.A detailed description is available in the specification document [64].
1) Dialect: Starting from the end, the dialect element specifies the programming language (i.e., the dialect) embedded in the eQR code.The ability to support more than one dialect permits to more effectively face the scarce storage capacity of QR codes.Specific dialects can be defined that provide different tradeoffs between compactness and expressive power, which suit different application contexts.It is worth pointing out that any increase in the computational complexity for decoding and executing the program embedded in the eQR code due to the specific type of dialect (and the related instruction set) is, from our perspective, irrelevant.In fact, the small size of the code that can be stored in an eQR code makes the effort for dealing with it always negligible compared to the computational power of the target device (e.g., a smartphone).At the time of writing, the only dialect we defined is the Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.QRtree dialect, which is aimed at implementing a decision tree inside the eQR code.In this work, it is described and analyzed starting from Section IV.
The dialect selector is encoded on (at least) 4 bits, followed by (at least) other 4 bits that specify its version.Both are coded using the exponential encoding (EC), which permits to encode integer quantities on a number of bits that grows exponentially.For instance, the current version (1) of the QRtree dialect is encoded as 0000 0001.This representation technique is used in many other parts of the QRtree dialect.
2) Exponential Encoding: The simple idea behind EC consists in doubling the number of bits used to encode an unsigned integer every time the initially allocated space (i.e., 4 bits for the QRtree dialect) is not enough to store it.For integer values between 0 and 14, the number of bits of the representation is 4 (e.g., 5 10 = 0101 EC ).Values between 15 and 29 are encoded on 8 bits, where the first 4 bits are set to 1111 (e.g., 18 10 = 11110011 EC ).Values between 30 and 284 are encoded on 16 bits, where the first 8 bits are set equal to 11111111 (e.g., 123 10 = 1111111101011101 EC ), and so on.
This representation guarantees both compactness and extensibility: 1) the number of bits used to encode any value is directly related to the value itself and 2) in theory, there is no upper limit on the values that can be encoded.
3) URL: In those situations when the end-user device has Internet access, the ability to exploit an URL to run a remote application in the place of the QRscript might be a more appropriate solution.Clearly, remote applications have almost no constraints about program size and are likely to provide (much) better user interaction.Moreover, since they run on a remote Web server, they could include a range of information types, like videos, sounds, and images, that can be hardly integrated within an eQR code for space reasons.This explains why we foresaw the option to include a URL within an eQR code.In particular, the URL bit identifies the presence of the URL.If the bit is 1, the subsequent bits encode the URL using UTF-8 encoding [65].The character end-of-text (ETX) is used as the string terminator.
At the application level, it is possible to configure a specific behavior once the selected URL has been requested, which refers back to the execution of the eQR code, allowing the possibility of deactivating the URL even after its generation.
4) Security: Properly managing security is of utmost importance for eQR codes, mainly to ensure their authenticity and integrity.The execution of a fake eQR code with malicious code may cause serious damages, possibly leading users to perform potentially dangerous actions.For certain kinds of applications, where the information included in the eQR code should be only accessible by selected end users (e.g., privacyprotected data), encryption could be optionally enabled.
The security element in the QRscript header exploits the exponential coding with an initial size equal to 4 bits, which represents the security profile used for the specific eQR code.The security profile indicates: which type of security is enabled; the parts of the eQR code that are involved; the specific algorithm (e.g., RSA); and the length of the digital signature that is possibly included within the eQR code.Security is disabled when the security profile is set to 0000.The application developer is in charge of defining a mapping between the values the security element can assume and security policies.This mapping is not defined in the specification document, and consequently it may differ for different applications.
5) Continuation: To overcome the size limit of QR codes, QRscript supports the concatenation of more than one eQR code.To this extent, the continuation element of the QR script header has been defined, which permits to identify the different sub-eQR codes to be merged, and in particular their overall number and order.After some basic operations for reconstructing a new header and concatenating the dialect codes, a new (concatenated) eQRbytecode is generated that can be directly executed by the end-user device.This makes it easy to double and even triplicate the maximum allowed size of eQR programs.In some contexts the application could be split over different eQR codes, placed in different locations and containing different pieces of program, which in their entirety enable the resolution of a joint decision problem.
6) Padding: The first bit of the eQRbytecode header identifies the presence of padding, which is needed only for QR codes with binary encoding in the case the length of the eQRbytecode is not an exact multiple of 8 bits.Differently from communication protocols, padding is added at the beginning of the eQR code (and not at its end), since it must be completely independent of the dialect that is embedded within the eQR code.In particular, 1 means no additional padding, whereas 01, 001, and 0001 mean 1, 2, and 3 additional padding bits, respectively, and so on (the maximum size of the padding element is 8 bits).In the case of numeric coding, the eQRbytecode is expressed as a decimal number and the presence of padding does not affect conversion because leading 0 s are not significant.

IV. QRTREE DIALECT
QRtree is a dialect specifically aimed at coding a decision tree within an eQR code.A decision tree is a structure composed of three kinds of nodes, namely, decision, end, and chance nodes.Chance nodes are not considered in QRtree, because they represent probabilistic decisions, which are not relevant for the application contexts to which this dialect applies.Decision nodes are the vertex of the tree and represent the conditions that allow the user to choose among the different branches of the tree, based on its answers.End nodes are the leaves of the tree, which provide responses to the user.A simple example of a decision tree is shown in Fig. 4(a).
It is worth pointing out that, even if the QRtree was conceived to efficiently embed a decision tree in an eQR code, other (different) languages could be also encoded using the intermediate representation defined by the QRtree dialect.However, due to the absence of variables and backward  jumps, most high-level programming languages cannot be represented through QRtree.In other words, the intermediate language of QRtree is not Turing-complete.We remark again that the QRtree dialect and the corresponding specification document [66] define only the conversion rules between intermediate language and eQRbytecode, which in the context of this dialect is named eQRtreebytecode.
The example that will be illustrated in Section V, sketched in Fig. 4(b), considers an eQR code aimed to guide hikers on a mountain trail.The high-level programming language reported in Fig. 6 can be easily translated into the intermediate representation of Fig. 7. Details about the QRtree dialect in such intermediate representation and its translation to the eQRbytecode of Fig. 8, as well as the reverse process, are thoroughly explained in the four sections below.

A. QRtree Structure
The part of an eQR code that contains the QRtree dialect is divided into two sections: 1) QRtree header and 2) QRtree Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Fig. 6.Example of a high-level programming language that describes the decision tree for helping mountain hikers.body (or code).The first section is optional and permits to (re)configure the encoding rules of the instructions included in the subsequent code section.
The QRtree dialect does not permit the definition of variables.There is only one implicit variable, which is named v_input, that is defined at the beginning of the execution and refers to the value acquired by the end user by the most recent input instruction.In the case of decision trees, the content of this variable is needed to select the branches of the tree that lead to a final output represented by an end node.In particular, v_input can be compared with constants (i.e., literals), which consist of strings, integers, and real values.

B. Data Types
The main data type of the QRtree dialect is the string, as it is used in both input and output instructions.Strings are quite space consuming, and hence much attention was devoted to encoding efficiency in dialect definition.In particular, the first two bits of a string identify the type of the string: ASCII-7 (00), UTF-8 (01), and DICT (10).The ASCII-7 [67] encoding relies on 7-bit characters, hence it only supports English-like alphabets.This limitation is overcome by the UTF-8 [65] encoding, which is a variable-length encoding (8-32 bits are needed for every character) where the final length depends on the dimension of the used character set.
The DICT type refers to predefined strings that are identified through numeric references in output instructions (instead of the whole string).Three types of dictionaries are defined, identified by the bits that follow in the string, namely, global (00), specific (01), and local (1).As highlighted in the specification document [66], if not all the three types of dictionaries are used, more compact representations are possible.Global dictionaries are generic dictionaries that contain frequently used words that suit a multitude of applications (e.g., "yes," "no," "maybe," etc.).Instead, specific dictionaries are typical of a given application context (e.g., "instruction manuals for boats," "mountains," "caves," etc.), and specific commands in the QRtree header can be used to activate them.Finally, local dictionaries are stored in the QRtree header itself.Typically, they can be used for strings repeated many times in the eQR code, which are stored only once in the QRtree header.Detection of such strings can be performed automatically during translation, by analyzing the occurrence of the strings within the eQR code and generating the corresponding local dictionary accordingly.The reference to a specific string within a dictionary is encoded as an unsigned integer using the EC described in Section III-B2.

C. QRtree Header
The QRtree header is optional, and its presence is indicated by setting the first bit of the eQRtreebytecode to 1.It consists of a list of six different types of commands, each one encoded on 3 bits with the EC.A specific HEADER_END command is defined as the terminator of the list.) and real (FP16 or FP32) values.This saves space, since specifying the representation of every single number is no longer required.The command DICT_TYPES is used to activate global and/or specific dictionaries, whereas DICT_SPEC_TYPE permits to select which specific dictionaries (one or more) are active among those defined by the application developer, specified using the JSON format [66].Finally, the DICT_LOCAL command permits to embed the local dictionary within the eQR code by using the specific syntax defined in [66].

D. Code
The code section follows the QRtree header and contains the list of instructions that make up the program.
1) Intermediate Representation: From the point of view of the intermediate representation, the seven instructions defined by the QRtree dialect are reported in Table III.An example of intermediate representation, which refers to the application example described in Section V, can be found in Fig. 7.It uses a three-address code, in which every instruction is identified/labeled with an integer in increasing order.
All the four input/output instructions (input, inputs, print, and printex) display information for the user on the screen, either a <string> (defined in Section IV-B) or a <reference>.The binary value <type> is used to distinguish between the two cases.
The option to output a reference (an exponentially encoded unsigned integer that points to an external source, e.g., a printed description) is a valuable feature of the QRtree dialect.One of the benefits of eQR codes, and QR codes in general, is that they can be printed on a physical support with some extra information next to them, like text or images.On the one hand, this can help users to understand how to use the eQR code and what is its purpose.On the other hand, references permit to move some parts of the program (e.g., long strings) outside the eQR code, leading to a consistent saving in terms of space.For example, strings related to explanatory text (descriptions/instructions) can be printed on the same sheet as the eQR code instead of being embedded within it.In this case, the program can simply output an indication to the user, inviting her/him to look at a certain reference.Besides strings, references can point to other kinds of information that cannot be easily embedded within the eQR code, like pictures and maps.
Another interesting point concerns input.In the typical case of direct input (instruction inputs), the answer is fed directly by the user through a textual interface.For indirect input (instruction input), the answer is obtained, for instance, by means of decision buttons that, for the execution step (arrow ⑥ of Fig. 2), are automatically derived from the if instructions of the intermediate representation.Indirect input permits to design more user-friendly user interfaces for the applications executed on end-user devices.
The goto instruction is related to unconditional jumps, while if and ifc instructions refer to conditional jumps.In particular, the if instruction compares the last string provided by the user, stored in v_input, with its <string> argument.If they match, a jump is performed to the corresponding label.Similarly, the ifc instruction performs a comparison between v_input and its operand <op>, using relational operator <rel_op>, chosen among == for equality, != for inequality, <=, >=, <, and > for order.Again, if the result of the comparison is true, a jump to the label is performed.The operand is one of the numeric datatypes defined in Section IV-B, namely, INT16, INT32, FP16, or FP32.The virtual machine running in the end-user application is in charge of performing the required data type conversions of v_input to the type of the operand.
Since the QRtree dialect does not support loops, only forward jumps have been defined, i.e., those which point to instructions that follow the current one.
2) eQRtreebytecode: A set of rules is defined for converting instructions from the intermediate representation to the binary eQRtreebytecode and vice versa.The first three bits identify the instruction.Pattern 111 was left unused to deal with possible extensions of the instruction set.Every instruction has its own conversion rules, which are specific to behavior and the operands involved in its execution.
licensed use limited to the terms of applicable license agreement IEEE.Restrictions apply.
As a first, simple example, the goto instruction is identified by the bit pattern 100, which is followed by a relative jump specified by the number of instructions to skip, coded using the EC.Thus, the eQRtreebytecode fragment 100 0000 means to jump to the next instruction.
The most complex instruction is ifc, whose conversion rules are reported in Fig. 5.In detail, the initial 110 pattern identifies the ifc instruction, the next three bits identify the relational operator to be used (rel_op), followed by two bits that identify the type of the operand, either INT16, INT32, FP16, or FP32 (depending on the settings in the QRtree header, more compact notations are possible for type).The type field defines how to interpret the following bits, which encode the literal, and what type of automatic conversion must be applied to v_input.Finally, exactly as in the goto instruction, we find the relative jump to be performed when the result of the comparison is true.
Details about the translation rules of the other instructions are reported in the QRtree dialect specification document [66].

V. APPLICATION EXAMPLE
As a concrete, simple example of the QRtree dialect, an eQR code is illustrated below that, once suitably placed on a mountain trail, helps hikers to choose a specific destination among several alternatives, according to their capabilities and preferences.
A simple compilation chain named QRtree [70], which relies on python and implements all the mandatory features listed in the QRtree specification document [66], was developed and released under the GPL-3.0license.All the steps of the example described in this section can be reproduced by executing the file named ex01-IEEE_IoT-J_mountain_routes.txt,which is located in the examples directory of the QRtree software.In the same directory another application example is included, named ex02-IEEE_IoT-J_defibrillator.txt,which is aimed to guide the user in correctly operating a defibrillator.The availability of easy-to-use technology like eQR codes could make the difference in case of emergency.

A. eQR Code Generation
The idea behind this example is to guide a hiker in the selection of the destination that best fits her/his current conditions and wishes, by asking a series of specific questions.In the generation chain sketched in Fig. 2, the application designer develops a decision tree, using a high-level programming language, that asks the hiker a number of questions and then provides the related advice.With reference to Fig. 6, the first question: "Are you tired?" permits to check the level of fatigue of the hiker.In the case the user is tired ("yes" response), the program proposes two alternatives within a short walking distance, "lake" or "forest."The first option leads to reference "1," while in the case, the answer is "forest" the program stored in the eQR code further investigates if the user is possibly willing to walk for one more hour (by means of the question "Do you feel like walking for an hour?").The related indications, for the "yes" and "no" (better, not "yes") answers, are provided as references "4" and "2," respectively.Conversely, if the user is still lively (i.e., the answer to the first question is "no"), the program asks: "How long do you want to walk (minutes)?",which requests her/him to enter a number expressed in minutes.This leads to recommending the "Alfredo Rivetti hut" (reference "3") if the answer is greater than 120 (2 h), or the "Madonna della Neve hut" otherwise.
Starting from this description, the intermediate representation reported in Fig. 7 can be automatically obtained by using the rules reported in Section IV and in the specification documents [64], [66].
The result of the conversion from the intermediate representation (in terms of the corresponding eQRbytecode binary representation) and the generated eQR code is reported in Fig. 8.As can be seen, the QRscript header starts with the padding 01, while continuation is disabled (the next bit is set to 0).Also security is disabled (0000), as well as the URL (0).The dialect is "QRtree" (0000), and its version is 1 (0001).The length of the eQRbytecode for this simple decision tree is 1872 bits (234 bytes), which corresponds to just 7.9% of the maximum capacity of a QR code.Most of the space is occupied by strings.It is worth observing that real applications are typically more complex, which likely means that they need to exploit a larger portion of the available space of the QR code.

B. eQR Code Execution
The execution chain permits to run the program embedded in an eQR code.The eQR code to be executed is typically embedded in a poster (other kinds of support are also possible) together with additional information, including pictures, textual descriptions, and maps.For example, the poster depicted in Fig. 9 includes a map that shows hikers where the various reachable places are located.The program considered in the current example outputs one of four possible references.For every reference, the poster includes a picture that visually shows the destination and some text that provides additional information.The poster could be placed, in the form of an indication sign, near a crossroad that permits to reach the four destinations.Let us assume that there is no Internet coverage.When the end user (a hiker, in the example) scans the eQR code with the camera of her/his (unconnected) smartphone, a suitable app (preinstalled in the device) transforms the content of the eQR code into the binary eQRbytecode representation, which can be directly translated into the intermediate representation.Starting from it, execution is possible by means of, e.g., a suitable virtual machine.In our proof of concept, eQR execution relies on a JavaScript application that can be run on any browser.Although this implementation is clearly not optimized (we are not pursuing a fully engineered commercial product at this time), it can be tested on both mobile platforms (Android and iOS) and conventional devices (Windows, Linux, and macOS).
The screenshot in Fig. 10 refers to a specific execution instance of the eQR code.The application initially asks the hiker if she/he is tired.Following the negative answer ("no"), the application asks how many minutes she/he intends to keep walking.Since the response is 180, which is greater than 120, the application outputs a message that invites to take a look at reference 3, which corresponds to the "Alfredo Rivetti hut." Although extremely simple, the above example shows all the steps involved in both the generation and the execution chain that apply to a concrete scenario concerning tourism, including a sample user interaction.Similarly to QR codes, which were conceived for industrial applications but can now be found everywhere in our lives, the possibilities offered by eQR codes are likely uncountable.Contexts in the real world that can benefit from this technology include methods to help people to easily find solutions to their problems (or simply the information they are looking for) when an Internet connection is lacking, and even to improve their safety by providing unambiguous guided instructions when needed.

C. Comparison
Since the room available in QR codes is scarce, the most interesting metric for assessing solutions like ours is code size.To the best of our knowledge, there are at the moment no competing solutions conceived for similar purposes.For this reason, we compared the size of the eQR code for the above example (see Fig. 8) with a semantically equivalent program (i.e., which does exactly the same things: the same sequence of questions are asked to the user and, for the same answers, the same advice is provided) written in Python.For the latter, the size of the source code is 537B (i.e., occupation is 18.2%), while the related bytecode takes 634B (21.5%).It is worth pointing out that, when the size of data is small (as in our case), generic compression techniques like ZIP and RAR are ineffective.Conversely, QRtree usage managed to shrink code size to 234B (7.9%), which is noticeably less than alternatives and permits packing more complex algorithms inside an eQR code.It should be noted that, the lower the overall size of the strings, the higher the relative space saving achieved by eQR codes compared to other encodings.

VI. CONCLUSION
As highlighted by the analysis we performed on the state of the art about QR codes, reported at the beginning of this work, the past years witnessed a promising trend concerning the research activities on this technology.The ability to embed an executable program (denoted QRscript) inside them, and a formal and agreed definition of eQR codes, are an essential step that further enhances QR codes and brings them new life.QRscript was conceived bearing extensibility in mind, and permits embedding a variety of dialects.In this work, the QRtree dialect is defined that specifically permits to encode decision trees.Its usability and potential have been illustrated through a real-life application example.
eQR codes close a significant gap regarding the ability to embed algorithms in a QR code, in such a way to enable interactive behavior, which somehow resembles the IoT, also when Internet is unavailable and both the system (object) and its user (human being) are offline.For this reason we believe that they have the potential to know a wide diffusion in the coming years.Future work includes, possibly, the standardization of the specification documents about eQR codes referred to in this work and the definition of new dialects, including a general-purpose language that fully supports structured algorithms.

Fig. 1
shows some examples of QR codes, including version 1, version 5, version 10, and other less usual formats.Refer to [8, Fig. 1] for an example of a QR code using version 40.

Fig. 4 .
Fig. 4. Two examples of decision trees: (a) general example showing their structure and (b) specific and concrete example regarding mountain trails (it will be expanded and discussed in detail in Section V).

Fig. 5 .
Fig. 5. Conversion rules from intermediate representation to eQRtreebytecode of the ifc instruction.

Fig. 7 .
Fig. 7. Possible intermediate representation obtained from the high-level programming language of the example.

Fig. 8 .
Fig. 8. eQRbytecode obtained from the intermediate representation and the corresponding eQR code.

Fig. 9 .
Fig. 9. Sample eQR code printed on a sheet of paper along with additional information (map, images, and text).The poster can be used as indication sign.

Fig. 10 .
Fig. 10.Instance of execution of the QRscript (QRtree dialect) embedded in the sample eQR code on a smartphone (virtual machine).
QR Codes: From a Survey of the State of the Art to Executable eQR Codes for the Internet of Things Stefano Scanzio , Senior Member, IEEE, Matteo Rosani , Graduate Student Member, IEEE, Mattia Scamuzzi , and Gianluca Cena , Senior Member, IEEE

TABLE I MAIN
APPLICATION CONTEXT WHERE QR CODES ARE EXPLOITED representation, which was named eQRbytecode.Inserting the eQRbytecode inside an eQR code (represented by arrow ③) is quite trivial, since suitable libraries are publicly available that can be used for generating conventional QR codes.

TABLE II MAIN
RESEARCH TRENDS ABOUT QR CODES (REFERENCE [**] REPRESENTS THIS ARTICLE)

TABLE III INSTRUCTIONS
DEFINED FOR THE INTERMEDIATE REPRESENTATION OF THE QRTREE DIALECT More in detail, INT_TYPE and FLOAT_TYPE commands are used to select a specific representation for integer (INT16 or INT32