Abstract
Keywords
Introduction
It is the solid fact that with the rapid development of Internet of things (IoT) technology, the number of connected devices is growing exceptionally. As statistically mentioned in the recent survey of Garner, within next 1 year, in 2020, the figure will reach 20.8 million. 1 Therefore, how to better utilize the massive collected data is the main focus among the different areas of research studies. Tremendous efforts have had been devoted not only from an academic perspective but also from the industrial evaluation; Internet of vehicles (IoV) is one of the most focused branches of integrating the existing technology of IoT with growing transportation desires, as a part of the solution of intelligent traffic. 2
It is undeniable that during certain traffic circumstances, traffic lights and speed monitoring are just not enough to help people and official associated personnel in daily life. A traffic emergency could be varied, complicated as a possible terrific traffic accident or simple as a routine traffic jam. However, pre-actions by way of obeying the strict rules are far more accepted than current quick responding as the post-reactions. Consequently, the practical use of Intelligent Traffic System (ITS) that could indirectly force the safer driving and decrease the rate of traffic accidents is realistically on demand.
Magnificently, much time and efforts had been spent on empowering such ITS which has brought countless benefits to the society. 3 In the meantime, the welfares brought by such intelligent systems are always carried along with the potentially problematic security issues. 2 This is where blockchain technology is introduced; that is, a blockchain is expected to resolve the security loopholes a traditional centric system could have. There are generally two vital aspects regarding data security protection an intelligent vehicle system should never risk—trust and privacy. 4 The decentralized characteristic of a blockchain-enabled system manages to build up a “trusted bits” concept that proves the extent of security level. In this case, it is more reliable to share personal data strictly from the users and more data would be collected which leads to an intelligent monitoring system. The trust unit and anonymity of blockchain also contribute to the concept that personal credit of an individual could be tied up tightly with one’s behavior on the vehicle. Hence, a safer driver always tends to be reputable.
The motivation of this research is to help the associated personnel to have an improvised understanding of current traffic status so that decisions could be made accordingly. In order to make the monitoring and management of live traffic a more effective coordination, this study is trying to bind individual credit with behavior performed on the road (scenarios like switching lanes) so that a safer driving thinking would be implanted to each individual’s mind. 5 None of governmental rules could strictly force creating a more friendly traffic environment, but efforts are to be undeniably made by the public. Consequently, actions could be taken accurately toward individuals who have a ruthless driving habit with such monitoring and management of intelligent traffic. Thus, this could reduce the chaos during the rush hours.
Furthermore, with blockchain representational credit token supported as a tamper-proof transaction record, 6 standard measures could be implemented on individual who would be uniquely associated with credit tokens so that the personal infamous behaviors would be record. Besides, collectively, related governmental departments would have more shared data which avoids the isolated information island.
In consideration of the nature of blockchain consensus mechanisms, Practical Byzantine Fault Tolerance (PBFT) is time-consuming compared to generic real-time digital payment; hence, a more sophisticated blockchain-enabled process is comprehensively presented. 7 In the anticipated process, two defined chains are used for a near real-time user experience but keeps same level of security and reliability.
In this article, it illustrates the skeleton of a smart vehicle monitoring and management system which is proposed based on currently widely used Vehicular Ad hoc Network (VANET) structure. 4 The basic components in this proposed design share no enormous difference how a VANET system should be, which are deployed on the road as an infrastructure, with communication modules. In hypothesis, the designed system will create and integrate a “credit-token” transaction based on blockchain. 8 Obviously, a credit token means personal reputation that in current scenario the credit scheme is only subscribed within traffic motoring platform. So, as to contribute a reduction of accident rate and establish a more friendly traffic environment, the article will focus on process of token payment in the scenario of occupying the public traffic resource such as switching the lane right or causing a traffic accident from a blockchain token system perspective.
Proposed experimental design
On the perspective of the infrastructure of vehicular communication system, Yuan and Wang 3 introduced blockchain as a decentralized network architecture to implement a ride-sharing service based on the blockchain-based ITS which provides seven-layer hierarchical system. On the perspective of application-oriented vehicular communication, Singh and Kim proposed a reward system based on blockchain to provide a secure and reliable peer-to-peer vehicular information transmission cloud that introduces Trust Bit as a ledger record of trustworthiness of vehicle behavior. 9 Still, a gap remains on how to implement modular components of the peer-to-peer vehicle-based communication that makes the topological scalability of such decentralized system possible. 10
In this section, an experimental design of a basic blockchain-based ITS demonstrated above is introduced. The mechanism proposed in general is established in the following assumptions: 11
Automobiles in this experimental design are all presumed to have fundamental LBS recorder.
Automobiles are all equipped with generic speed recorder installed.
Automobiles are expected to be the essential part of this ITS, that is, in each blockchain system node, a smart contract processor is enforced.
IoV-oriented module design
With current advanced hardware support, IoT devices are now powerful enough to empower a relatively sophisticated ITS. In this proposed experimental ITS, the following listed components are fundamental ones.
Roadside Unit
A Roadside Unit (RSU) in this trial ITS mainly consisted of a central sensor controller, a Wi-Fi module which supports router/AP (access point) mode functionalities, necessary sensors, as well as other essential peripherals. It introduces Arduino as the central controller of RSU, which contains the ATmega328p microcontroller. For Wi-Fi transmission component, it introduces ESP8266 and LoRa 433 MHz module.
Arduino is the prototype circuit board often used for quick development. It consists of an Atmel chip Atmega328p (8-bit AVR Microcontroller) and necessary resistors, capacitors, and so on. Using its exposed universal asynchronous receiver-transmitter (UART) port, a Wi-Fi module ESP8266 is connected using serial communication. The Wi-Fi module ESP8266 is a low-cost system on chip module that uses a 32-bit Microcontroller and supports IEEE 802.11 b/g/n Wi-Fi transmission. Apart from Wi-Fi connection, an RSU is also expected to utilize a long-range wireless communication protocol which allows smaller packets of data sent between RSU peers. LoRa is the representative product of such low-power and wide-range radio frequency transceiver. It is part of low-power and wide-area solution. 12 In this project, 433 MHz is selected, which is a lower frequency, because according to Silicon Labs, the lower frequency always has the advantage on range and power consumption. 3 The hardware structure of the RSU is shown in Figure 1.
The hardware structure of proposed RSU.
In order to comply with the stability of connecting between devices, the potential problematic issues should be encountered in real world were taken into account when designing the module. For instance, both Wi-Fi module and the LoRa module were prepared for wireless communications if there are defects in any of the above-mentioned parts. Correspondingly, power supplies are separately provided toward the Wi-Fi module, LoRa module, and the main microcontroller unit (MCU, which usually be taken as a less powerful central processing unit). Heatsinks are also applied on each of the power module. In such way, it is easier to switch a broken part of an RSU swiftly.
On-Board Unit
As shown in Figure 2, an On-Board Unit (OBU) is such an application unit which could be plugged into existing vehicle electronic system with the original GPS (Global Positioning System) supported, with the network connection reinforced.
The user interface of proposed OBU.
Intermedia Server Unit
Intermedia Server Unit (ISU) is an intermedia component which basically connects crucial communications between devices at a lower layer like an RSU or an OBU and the centric platform. In this proposed ITS, an ISU is also the consensus server that carries strong algorithm chip that allows an ISU as a “validator” in the sense of PBFT consensus algorithm. Also, an ISU as a validator has an account which is comparatively a public account and this account should act as an intermedia credit holder that normally receives the payment from an individual without a certain ensured receiver.
The token pool and ISU devices were proposed to build a more efficient blockchain empowered system. By introducing ISU devices as trusted validators, the tangible number of participants for verifying each transaction reduced more than 50%. In addition, with more information and data gathered from surrounding RSUs, one ISU could provide statistically more processed information up onto cloud for further calculations which speeds up real-time response on token transactions. An intermedia pool is always there for a rapid reaction on each operation, but the final confirmation could be emitted afterward. Thus, the public token pool offers a great observation on transparency of ledger, delivering an approval queue.
Overall picture of the ITS design
The key components in this tentative traffic management system include RSU, self-intelligent vehicle (automobile) system, and the centralized cloud-based blockchain platform, and so on. Specifically, an RSU is always a vital part of any VANET which is mainly responsible for tasks such as traffic monitoring, lane flow surveillance, as well as a data node transceiver between the cloud-based platforms and vehicles, and is also a possible powerful router/AP for each data source node (vehicle/automobile) in order to provide a relatively stable network connection. 4 In this case, there is no difference between how an RSU is usually used and the centric platform is the research on trusted token contract platform supported by blockchain. Figure 3 shows the detailed design concept of ITS.
The overall illustration of the ITS.
Explicitly, when actions are performed by each OBU (a vehicle/automobile as shown in Figure 3), transactions between vehicles or toward the centric infrastructural token trade platform will be stored as tangible data on blockchain . As a vehicle-to-vehicle token communication happens, an actual valid transaction log/record will be inserted immediately to the centric blockchain-based platform which could not be revoked. However, this does not illustrate the tangible payment itself instantaneously; the record will then be validated all the way from cloud-based platform to the destination OBU account according to the near real-time information gathered from RSU. The specified process of token trade from pre-action to post-action behaved by each OBU is shown in Figure 4.
Action flow of the token payment scenario.
According to the transaction action flow above, there are primarily two core chains:
Action log chain: It is a distributed record system which is always verified instantly with the initial payment request information for real-time readiness purposes.
Payment chain: It is the core-linked chain which is used as the transaction sequence and it is where a solid payment happens. Ideally, the transaction status will be updated and synced periodically for each OBU, consequently, with various conditions of network quality.
Blockchain-based ITS structure
In order to make the initial summary of proposed ITS with the special blockchain services, the generic architecture layers and facilitated services are listed as follows.
Cloud computing service layer
Current traffic status analysis system: This is a fundamental system that introduces the functionalities which are used to analyze the traffic status after collecting the real-time traffic condition data.
Factor computing and analysis system: It is a core computing system that computes the factor of the traffic system and provides the relevant strategy to analyze the data sourcing from the computing system.
Transaction token coefficient evaluation system: It is a system that operates the transaction stream in a synergic and consensus mechanism in order to ensure the integrity and robustness of the transaction process.
Information collection layer
Collect real-time information from ISUs and RSUs: The main difference between information gathered by an ISU and an RSU is the perspective of collective behavior. An RSU is an 8-bit Microcontroller–based module which collects data passively. Generally, the common monitoring data like vehicle speed are collected from an OBU unresponsively. In addition, the data packets from an RSU are usually much smaller and the transmission frequency is higher. Comparatively, an ISU collects the data in a more active way, for example, the real-time traffic conditions such as accident detection because of switching lane behavior. Furthermore, as explicitly explained in the following sections, the initial analysis of those real-time actively collected data happened in ISUs. Being a part of the whole designed blockchain system, an ISU plays a vital role as a trusted validator which implies that actions are to be executed toward both directions. In another way, ISUs are the distributed brains for monitoring and capturing useful information using certain mechanisms that are based on historical data analysis, as well as a consensus algorithm supporter which contributes as the hardware level of trusted nodes. ISUs are the data consumers rather than just a data collection module, while RSUs are more likely to be described as data transceivers in order to provide data.
Historical traffic monitoring data storage: In this project, the historical data sent from all on-road modules (ISUs, RSUs, and OBUs) are simply extracted and loaded to the data pool. Statistically, the size of data grows exceptionally which could bring the problem of final transform and query speed. There are two layers of controllers that benefit the actual query time. The first layer from a transform perspective is the “tagged zone,” that is, not all the data are analyzed when an analysis request comes, but, accordingly, the real-time data are analyzed immediately with specific tags for quick search mapping. It is easier to distinguish which part of the analyzed results should be transformed into the requested format with such tag on previous data. Another layer of buffer for data storage is the “pivot graph;” this layer mainly focuses on virtually visualizing the relationship between the data packets within a current range of time. In this way, the complicated corrections could be validated and timely updated as transmitted data from on-road units. Hence, the size of the data collected from all the IoV devices should not have terrific influences on real-time cloud-based computing, and the evaluation could be sent back to clients within a responsive time.
Rich and detailed information provider: All the data collected by ISUs could be recognized as rich content that fundamentally offers more traffic status. Strategically, the rich content and details are more important in the long term as the more sophisticated data model or machine learning algorithm could be applied on. Thus, this is the effective way of improving the data cleaning and analysis process and contributing a more intelligent system which could regulate the expected results reasonably.
Blockchain service
Shared ledger system: It is the core system of blockchain, which provides a common sharing ledger service, that groups all blockchain service nodes within the ITS as one consolidated distributed system. 13
PBFT consensus system: As mentioned above, the PBFT algorithm is such a vital consensus mechanism which ensures that the blockchain could operate and synchronize in such a real-time distributed traffic system. 7
Token payment validation system: The distributed mechanism of blockchain transaction indicates that the token payment process is not directly confirmed unless the consensus of process is completed, and the validation of transaction data is validated. Hence, the system is introduced here to provide such functionalities. 14
Blockchain nodes
RSU, real-time traffic data supplier, and distributed node for supporting payment validation: An RSU is relatively cheaper and low-power node compared to an ISU. Hence, RSUs are more distributed placed along the roads. It has a moderately weaker “brain,” an 8-bit Microcontroller which defines its basic role as a simple data collector and transmitter in the whole designed IOV system.
ISU—authorized validator for PBFT-based payment chain: An ISU is much more powerful as it is expected to behave as an intelligent node and a validator of blockchain consensus mechanism in the blockchain system. It is composed of a real full-functioned CPU based on ARM architecture. In this project, a Raspberry Pi 3 Model B+ is used to perform the same role of an ISU.
OBU—personal account based on vehicle application: Supposedly, an OBU should follow the design rule of existing car models as well as electronic system sits on this specific automobile. However, as an experimental application, an OBU is represented with an Android application which is presumed to be running on vehicle-mounted system. It consumes peripheral modules a modern vehicle system normally has, for instance, GPS.
Currently, several commercial cloud service platforms have introduced and provided the blockchain-based system. They mainly focus on the features of irreversibility and traceability of blockchain and highlight the service as a store-and-proof service. As an experimental system design, the blockchain service involved in this case is the Blockchain-as-a-Service (BaaS) provided by Ant Financial Services Group. Ant Financial Service Group is a FinTech company affiliated with the Chinese Alibaba Group. Ant Financial Platform offers various cloud-based services such as Intelligent Financial Analysis platform, Machine Learning platform, and also the blockchain service used in this project. In comparison with other existing cloud-based service platforms, Ant Financial Platform just focuses on more aspects related to data support and financial analysis–associated services. More importantly, Alipay, which is the most valuable third-party payment platform provided by Ant Financial Service Group, is primarily based on a credit-oriented system that fits perfectly in scenarios studied in this article. 15 The proof-based blockchain service was particularly preferred than the other offered smart contract services. This is because that only token trade payment required strict verification and actions performed by each node should only be logged, while a proof-based blockchain service is currently enough for all the possible scenarios tested. In order to make both ISU and RSU on the road more intelligent as assistants and also more qualified as validators for consensus algorithm, the extra application layer was implanted in between the blockchain service provider and the cloud computing platform. The data collected from ISU and RSU such as the traffic status or accident reports, together with all the executed actions by each OBU node, and so on, will be warehoused into the centric database through the application. In this way, more information and data could be taken as the historical leaning resources for possible machine learning training on the distributed contribution fixed points. It is always believed that a more advanced RSU/ISU should be ingenious enough to have more knowledge on the traffic condition of monitored lane/road. Thus, whenever there should be an action request with initial payment details from an OBU, the information collector will be able to offer more solid data to end computing algorithm which would ultimately evaluate a more sensible token trade request onto the payment chain.
Comprehensive application design
In this section, the detailed design of both information collector and the distributed application sits on each node will be included. Apart from that, a deep dive of this proposed blockchain-assisted traffic system on a process perspective is to be introduced accordingly with the certain scenario.
As shown in Figure 5, it is clear that each OBU is actually represented by an individual’s wallet account which implies that instead of payment on the behaviors executed by a vehicle, it takes the responsibility back to the person. 16 And as a devised distributed system, all the requests sent are to be discrete nodes rather than the centric application. It is known that one of the main purposes to introduce blockchain technology into the ITS is to achieve a decentralized applicable structure design. However, there is always such limitation that none could be guaranteed with absolute no-centric controller, as in this case, the relatively static points (ISUs) as steady validators without algorithm-based election could cause potentially problematic issue in the future. For instance, if all the ISUs should be installed at certain fixed spots along the road side, it could be the circumstance that data security is vulnerable and is easily hacked. In other words, as long as there are enough nodes as ISUs, this vulnerability could be resolved. Also, as an information collector, the inevitability of making it a distributed application server is comparatively lower. 17 Because no solid payment that had gone through will be verified through this platform, it infers that vicious data implanted to the system should be ignored in the long term. From a historical data analysis point of view, the malicious information could have been flood away by the massive real-time data gathered.18,19
The orchestration of proposed ITS based on blockchain platform.
Detail data flow design
Generally, the complete data flow involves data collection from IoT modules to the centric data service layer and reply the near real-time reply back to the discrete blockchain application node for post-actions. Figure 6 shows the simple description of the above drift and it is clear that the component DataHub service actually manages the in-and-out stream of all data packets.
Overview of the ITS data flow.
In order to make sure the integrity of data streaming into the cloud-based service application layer, it is always important that no extra malicious data should waste the limited Internet bandwidth; in other words, an initial data filter pipe just makes the system extra effective with a basic protection of cloud-based application simultaneously. The real-time log convertor is enabled on each blockchain node which translates the raw data into the package of information that cloud service will recognize. Figure 7 descriptively defines the exact data wrapper offered by each log convertor as a data initial filter setting in each distributed blockchain node.
Pre-defined structure of blockchain data node.
The “Start Bits” and the “End Bits” are enumerable data which illustrate that the carried body is transmitted by a qualified blockchain client node and the data are to be uploaded to online service that has enough legality not to violate the whole system. Any accidental change to the transported raw data would raise the possibility of turning the current node into a vulnerable point. As a double safety check chain, “CRC Bits” section is continually designed, and cyclic redundancy check is thus a follow up of the traditional strategy of communication protocol. The “Mark Bits” is simply intended to help the service better distinguish the type of the transmitted data, whether or not those data packets should be analyzed in real time through the supported cloud computing or loading to the waiting block of historical data storage. And also, the chief purpose is to verify whether this piece of information should be from the isolated client request toward the two sorts of blockchain. It might have been such a case that the real-time information gathered by a group of RSUs could not be decided instantly if it is feasible for a real-time evaluation as a single node point of view. That the genuine decision of in which pool should the collected data stream into would have a larger chance made by the service itself. It is clear that this centralized service layer is the main brain which empowers with analytic functionality as well as a potentially learning ability as the massive data storage back-up.
There are essentially three parts consisting of the centric service layer for collecting information from distributed nodes. The DataHub service, the essential business logic controller, manages the data flow either toward real-time piping for simultaneous calculation or streaming the data to a data warehouse. The pre-action before the complicated definite business logic could be applied onto the roughly processed data, which is performed by the Data Filter/Blocker. The following are the detailed responsibilities of the Data filter/Blocker:
Checks data integrity accordingly with the default data pack wrapped by the mentioned log convertor above.
Based on the “Mark Bits,” the preliminary shunting of data happens.
Logs down the “Blocker” activities with the uploaded node identity in order to ensure whether any node has had become an untrusted client. The afterward actions could be then taken in the next steps.
When it comes to the central brain in the application service controller level, the system was not yet designed as sophisticated as it is supposed to. But a brief discussion will be shown below. The key business logic of the DataHub service layer includes two separate aspects: (1) the clever way of distinguishing if a blockchain-related request is sent from a trusted node and (2) how to make the data flow a more intelligent way of piping into different system.
The first task, which is to manage the data source, is currently designed appealing straight forward by tagged data package as well as the default meta data in each data package. As there is a data pool existing already which is recorded by the “Data Blocker,” each recorded log should have the malicious data and a tag of vulnerable source point in the whole system. The grading strategy acts with a default threshold, any data source that should reach that edge grade will be marked as dangerous. However, there is no definite decline towards any particular data source which had been marked as ‘untrusted node’ only shows a warning and collected as historical data. This mechanism is designed in this way as the distrust strategy should be adjust accordingly based on the resulted data analysis. The ideal way of managing this is displayed in Figure 8.
Obviously, a new component “Smart Picker” is considered to be an extra helper for optimizing the whole data flow strategy. In the current design, when each time a new request has to be validated with its data source historical records, the service application is required to be powerful enough to check the data in the “Data Pool.” As there are more data poured into the data warehouse, the service layer should have more difficulties to manage all the requests from multiple places. The ability of handling the concurrent requests is thus questioned.
As a result, the purpose of the “Smart Picker” is to reduce the workload of the main brain in the service application layer as to constantly pick up the data sources that reached the level of trust failure limitation. In the future work, there should be a standing connection between the central service brain and the “Smart Picker,” while in case if a new block has to be inserted, the “Smart Picker” will get automatically notified and easily skim the related records of the current data source. If this specific node should be untrusted, the “Smart Picker” should then push the trigger to the computing unit which would ultimately influence the evaluated results, for example, maybe in some cases that the untrusted node should be taken out all the available tokens. In this sense, presumably, certain punishment could be applied on in a more reasonable way.
Finally, after the payment request is logged onto the first record chain, and coefficients are calculated, an approval and the new payment data encrypted will be sent back to the original source requestor. Spontaneously, the mechanism works in the way that the OBU will again send this data pack which is currently approved by multiple steps of skimming and evaluations. From the driver/user’s point of view, there is no noticeable feeling that a second transaction request has had been sent. The only notification one user should receive is the finalized result of the payment due to actions. Consequently, one’s behavior on the public traffic system should ultimately generate certain influences on his or her own personal credit as all OBUs are based on solid account.
Data pool requests’ flow on cloud computing.
Blockchain-based ITS implementation
Credits-based system strategy and algorithm
Strategically, the influences of an action are always analyzed near real-time in order to make sensible payment approval as this system is what personal credit is tied up to. Depending on the actual impacts on both the traffic condition and the other OBUs, the strategy would intelligently make the decision how to modify the opening transaction request. Not only the count of tokens but also the receptionist should be altered. 20
As shown in Figure 9, there are scenarios that one transaction goes through from one individual’s account to another but also could be changed to a credits pool that holds for public as assets by an ISU. This influence verification strategy is generally made out of two influence factors: impacts through the time range on current path and the effects on other OBUs.
Scenarios of credit token payment.
In equation (1), it roughly describes the related aspects of resulted effectiveness of an action. Therefore, this would give an assessment whether the transaction should be passed onto only one account or contribute to the entire system
The essential algorithm which offers the elementary transaction is the coefficient evaluate algorithm. This algorithm basically sets up the strategy in order to manipulate the initial payment request originated by the OBU account. The specific equation used for this evaluation policy is displayed below.
Blockchain application implementation
In this section, the two different chains are to be presented along with all the comprehensive application-based concepts and also the specified implementation-level explanations.
As a viewpoint of the concept design, there is always one data schema allowed for the payment request data body as “Transaction” which is indicated in Table 1. 22 The restriction is actually on the BaaS platform provided by Ant Technology that the default SDK (Software Development Kit) only supports limited defined types of data schema. The data schema includes basic information of a transaction block: “op_time,” the operation timestamp, and “user_id,” which represents the unique user identification mapped with blockchain application account. The number of tokens requested to be transferred is defined as “count” along with another data field “opt_type,” the payment type. Apart from all these necessary fields, there are two other important fields, namely, latest block Id “pre_txHash” and an encryption public key Id “pub_key_id.” The public key Id is actually the additional locker of the transmitted payment information rather than the encrypted communication within the blockchain network. To put this in another way, this public key here is just the same as the public key which verifies the transaction source as the normal blockchain-based payment strategy.
The fields of transactions.
From a payment scenario–based perspective, there are two dedicated transaction means as shown above. One is from an individual’s account to another individual’s account corresponding to the switching-lane-alike scenarios. The other token payment operation is that credits are taken from one individual’s account to the relatively centric reward pool. The credits pool is now equipped as the public validator account on each ISU as mentioned above in the description of an ISU that an ISU is also a credit receiver.
The basic scenario of transaction between two peers’ accounts could be described as follows: the case that one account-based OBU required a lane switch, while the other account-based OBU should be affected during driving under that traffic circumstance and no other individual have had then been influenced continuously. In summary, the one-to-one account-based transactions happen only when actions are taken without a predictable chain reaction.
On the other hand, with such busy traffic conditions, once a vehicle switches its lane in the middle of the road, other vehicles are also affected. As a result, under such scenario, the token payment is to be transferred to a “credits pool” that holds certain amounts of tokens awaiting to be allocated. In current design, there is no mechanism to optimize the re-distribution of the credits collected, but as ISU is becoming more intelligent, this should be included in the future work.
Security concerns on blockchain-based ITS
The blockchain-based ITS proposed in this article illustrates a comprehensive solution that contains (1) IoT devices integrated by IoV nodes, distributed processor nodes, and communication intermedia; (2) blockchain-based system deployed on BaaS to serve the data and payment transactions; and (3) ITS itself as a software to support the whole solution. Hence, in this section, the viewpoints on these three perspectives to highlight the issues concealed in this proposed system are explained. Furthermore, it also put eyes on the data security and privacy as a fundamental requirement for an online system.
Infrastructure concerns
As the system proposed above, it is mentioned that the potential issues could happen on the IoT system.
Hardware destruction
RSUs and ISUs are deployed on the road, which means it causes potential risk that nodes could be destroyed or hacked.
In the architecture proposed above, the mechanism to avoid such hardware destruction is to multi-deploy such spotted nodes as a distributed network so that the data through the system could be synced in consensus method which reduces the possibility of single-point attack issue.
Network attack
There are two typical network attack circumstances:
Sensitive data protection
In intelligent traffic context, data are sensitive, even the speed of vehicles, either generally coordinating the traffic condition in a macro-view or giving reactions from specific relevant vehicle in a micro-view. 24
With blockchain integrated, it may raise three aspects of security: 23
Conclusion and future work
In the future, with the rapid development of artificial intelligence, and the coming evolution of wireless communication on 5G, the intelligent traffic is shaping into a comprehensive solution with a large scale of IoT devices being connected and communicated with each other that the traffic condition could be predicted and fore conducted. Furthermore, more intelligent system will be introduced as the revolution of the future intelligent world.
This article mainly focuses on the design and implementation on the blockchain-based ITS which cloud automatically collect traffic condition information and identity the traffic accident. Within this system, as a blockchain-based system, the chain is used to implement the transaction record for data transmission and traffic condition transformation between vehicles.
However, several vulnerabilities still remain in such an ITS:
The security concerns of hardware deployments with a distributed control processor;
The communication issues on time delay and data leakage.
Furthermore, to integrate into the blockchain system, it reveals the following issues:
The raising energy consumption of IoT devices;
The increasing communication demands on the network throughput;
The expansibility of the solution with a pre-defined existing blockchain service system.
As mentioned above, it is expected that the blockchain-integrated ITS could be more powerful and efficient. It could reduce the human interferences and external malicious attacks in general, which allows the vehicles and traffic relevant objects to communicate and self-execute automatically with blockchain smart contract according to the traffic conditions.
In future works, it is necessary to consider on how to improve the efficiency of operating the blockchain-based system on the embedded system with low-energy consumption and the limitation of blockchain smart contract that could enhance the system expandability. Furthermore, it is expected to work on the machine learning algorithm which could identify the traffic accident and predict the traffic condition and the consensus algorithm of blockchain in order to enhance the tolerance and transaction rate of a real-time system. Explicitly, the main reason why machine learning mechanism is eagerly accomplished during the integrated extract, load and transform (ELT) data process is that not just a more effective system could be established but also a self-improvising and self-managing service would be built based on such continues learning ability. The analyzed results from collected sensor data and the rich content data from on-road modules will be absorbed so it is obvious that each time the quantity analysis will have one step toward accuracy. This indicates that the on-road modules especially the ISUs which are mainly responsible for concentrating rich format of data could adjust the collection strategy on account of the bias statistical analysis results. In other words, the ISUs, in particular, tend to actively collect more useful data and, consequently, such machine learning could be applied on. Periodically, the data collection strategy of on-road ISUs will then continue to have impact on the next level of analysis of processed data and produce more valid evaluations to meet expectations.
Footnotes
Declaration of conflicting interests
Funding
ORCID iD
