Method for automatic transmission of open charge point protocol messages and test senario drive for the same

Abstract

The present invention relates to a method for automatically transmitting Open Charge Point Protocol (OCPP) messages in a test scenario driving device that simulates compatibility between at least one charger and a Charging Station Management System (CSMS), comprising: receiving a scenario setting file including connection information between the charger and the CSMS and OCPP message information transmitted and received between the charger and the CSMS; creating a charger simulation model to simulate a virtual charger operating according to the input scenario setting file and establishing a connection between the charger simulation model and the CSMS according to the connection information of the scenario setting file; and automatically transmitting at least one OCPP message defined in the scenario setting file to the CSMS to test the charger simulation model.

Description

Technology Field

[0001] The present invention relates to a method for automatically transmitting Open Charge Point Protocol (OCPP) messages and a test scenario driving device for the same. Background Technology

[0003] Recently, as the depletion of fossil fuels and air pollution caused by overuse have become serious issues, research and development regarding the use of renewable energy and eco-friendly transportation methods are actively underway. Among eco-friendly transportation options, electric vehicles (EVs) emit no air pollutants during operation and do not cause noise pollution, leading automakers worldwide to rush to launch them into the market. Furthermore, countries around the world are striving to develop and install EV charging systems to facilitate the widespread adoption and smooth use of these eco-friendly electric vehicles.

[0004] Meanwhile, with the recent rapid increase in the adoption of charging points, internationally interoperable standard protocols are being proposed for the efficient management of chargers or charging systems. Consequently, there is a growing trend in Korea to switch to charging network protocols that adhere to international standards in order to secure a leading position in the market.

[0005] For example, the Open Charge Alliance (OCA) distributes OCPP as a protocol for electric vehicle charging systems, and standardization work is currently underway with OCPP 2.0 incorporated into the IEC 63110 standard. OCPP is an application protocol for communication between electric vehicle chargers and Charging Station Management Systems (CSMS); it is an open application protocol that enables a central management system to communicate with electric vehicle chargers and various charging companies. This OCPP is currently applied and used in numerous electric vehicle charging stations and central management systems worldwide.

[0006] Meanwhile, chargers are generally connected to CSMS via WebSockets to exchange OCPP messages. However, if a charger is not available, the connection and operation with CSMS must be tested through a simulator by manually clicking on each OCPP message one by one, which requires a large workforce and incurs significant time and cost.

[0007] Therefore, research is needed on methods to test the connection setup and operation with CSMS in the absence of a charger. Prior art literature

[0009] Korean Patent Publication No. 10-2024-0075191 The problem to be solved

[0010] The present invention was devised to solve the above-mentioned problems, and the objective of the present invention is to provide a method for automatically transmitting OCPP messages and a test scenario driving device for the same. means of solving the problem

[0012] A method for automatically transmitting OCPP messages in a test scenario driving device for simulating compatibility between at least one charger and a CSMS according to an embodiment of the present invention for achieving the above objective comprises: receiving a scenario setting file including connection information between the charger and the CSMS and OCPP message information transmitted and received between the charger and the CSMS; generating a charger simulation model for simulating a virtual charger operating according to the input scenario setting file and establishing a connection between the charger simulation model and the CSMS according to the connection information of the scenario setting file; and automatically transmitting at least one OCPP message defined in the scenario setting file to the CSMS to test the charger simulation model.

[0013] A test scenario driving device according to an embodiment of the present invention for achieving the above objective, which automatically transmits OCPP messages to simulate compatibility between at least one charger and a CSMS, comprises: an input unit that receives a scenario setting file including connection information between the charger and the CSMS and OCPP message information transmitted and received between the charger and the CSMS; a connection setting unit that generates a charger simulation model to simulate a virtual charger operating according to the input scenario setting file and sets a connection between the charger simulation model and the CSMS according to the connection information of the scenario setting file; and a test unit that automatically transmits at least one OCPP message defined in the scenario setting file to the CSMS to test the charger simulation model. Effects of the invention

[0015] According to one aspect of the present invention described above, by providing a method for automatically transmitting OCPP messages and a test scenario driving device for the same, it is possible to test the connection setup and operation with CSMS without a charger.

[0016] In addition, since tests can be performed without an actual charger, the cost of purchasing or installing a physical charger is reduced, which results in significant cost savings, especially when multiple chargers need to be tested.

[0017] In addition, the safety of the system can be enhanced by simulating various scenarios, and the reliability of the CSMS can be increased by verifying how the CSMS responds to various OCPP messages and whether the response is appropriate. Brief explanation of the drawing

[0019] FIG. 1 is a diagram showing an electric vehicle charging system configured for automatic transmission of OCPP messages according to an embodiment of the present invention. FIG. 2 is a device diagram showing the internal blocks of the test scenario driving device of FIG. 1, FIG. 3 is a diagram showing an example of connection information and additional information between the charger and the CSMS in a scenario setting file. FIGS. 4a to 4c are drawings showing examples of OCPP message information transmitted and received between the charger and the CSMS in a scenario setting file. And, FIG. 5 is a flowchart showing the operation of a test scenario driving device according to an embodiment of the present invention automatically transmitting an OCPP message. Specific details for implementing the invention

[0020] The following detailed description of the invention refers to the accompanying drawings, which illustrate specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that various embodiments of the invention are different but need not be mutually exclusive. For example, specific shapes, structures, and characteristics described herein may be implemented in other embodiments without departing from the spirit and scope of the invention in relation to one embodiment. It should also be understood that the location or arrangement of individual components within each disclosed embodiment may be changed without departing from the spirit and scope of the invention. Accordingly, the following detailed description is not intended to be limiting, and the scope of the invention is limited only by the appended claims, including all equivalents to those claimed therein, provided they are appropriately described. Similar reference numerals in the drawings refer to the same or similar functions across various aspects.

[0021] The components according to the present invention are defined by functional distinction rather than physical distinction, and can be defined by the functions each performs. Each component may be implemented as hardware or as program code and processing units that perform each function, and the functions of two or more components may be included and implemented in a single component. Therefore, it should be noted that the names assigned to the components in the following embodiments are not intended to physically distinguish each component but are assigned to imply the representative function performed by each component, and that the technical concept of the present invention is not limited by the names of the components.

[0022] Preferred embodiments of the present invention will be described in more detail below with reference to the drawings.

[0023] FIG. 1 is a diagram showing an electric vehicle charging system configured for automatic transmission of OCPP messages according to an embodiment of the present invention.

[0024] The electric vehicle charging system described includes a test scenario driving device (110) and a CSMS (130).

[0025] The test scenario driving device (110) is a device that simulates compatibility between at least one charger and CSMS (130) and manages the automated transmission of OCPP messages and scenario-based testing. That is, the test scenario driving device (110) tests a charger simulation model for simulating a virtual charger by automatically transmitting OCPP messages.

[0026] CSMS (130) refers to a central system that manages and monitors the charger network, monitors the status of the charger simulation model, generates a response to the OCPP message, and transmits it to the test scenario driving device (120).

[0027] FIG. 2 is a diagram showing the internal block of the test scenario driving device of FIG. 1, FIG. 3 is a diagram showing examples of connection information and additional information between the charger and the CSMS in a scenario setting file, and FIG. 4a to 4c are diagrams showing examples of OCPP message information transmitted and received between the charger and the CSMS in a scenario setting file.

[0028] The illustrated test scenario driving device (110) includes an input section (112), a connection setting section (114), and a test section (116).

[0029] The input unit (112) receives a scenario setting file containing connection information between the charger and the CSMS and OCPP message information transmitted and received between the charger and the CSMS. By injecting the scenario setting file through the input unit (112) in this way, the test scenario driving device (110) can drive the test scenario without modifying the code.

[0030] The connection setting unit (114) generates a charger simulation model for simulating a virtual charger that operates according to the input scenario setting file, and establishes a connection between the charger simulation model and the CSMS according to the connection information of the scenario setting file and at least one additional information.

[0031] As shown in FIG. 3, the connection information includes CentralStationUrl field information, and the CentralStationUrl field represents a WebSocket URL for connection with CSMS. Here, "ws: / / localhost:18050" refers to the Internet Protocol (IP) address and port of the local server, and "TT00000001" refers to the unique identifier (ID) of the charger.

[0032] In addition, the above additional information includes at least one of the field information of VendorId, idTag, connectorId, maxPrice, and phoneNumber. In the embodiments of the present invention, the field information included in the above additional information is shown as one example, and it is obvious that the above additional information may further include other field information.

[0033] The field information included in the above additional information is configured to match the CSMS, and if there is an identical key among the information in the above additional information in the scenario setting file shown in FIGS. 4a to 4c described later, the corresponding information in the scenario setting file is replaced with the information shown in the above additional information. For example, when the idTag field information of the above additional information is written as 00001, the idTag value of the scenario setting file is replaced with 00001.

[0034] To explain the field information included in the above additional information in more detail, the VendorId field represents the identifier of the charger's manufacturer or supplier.

[0035] The above idTag field represents the user's identification tag and, for example, may be a Radio-Frequency Identification (RFID) card or a unique identifier of an application used by the user to start charging.

[0036] The connectorId field above indicates the connector identifier connected to the charger, where "1" means the first connector.

[0037] The maxPrice field above indicates the maximum price allowed in a charging session, and for example, 4000 may mean a cost of up to 4000 won.

[0038] The above phoneNumber represents the user's phone number and can generally be used as an emergency contact or an additional authentication method.

[0039] The test unit (116) automatically transmits at least one OCPP message defined in the scenario setting file to the CSMS like a charger to test the charger simulation model generated through the connection setting unit (114). That is, the test unit (116) transmits at least one OCPP message according to the order defined in the scenario setting file, and after transmitting the first OCPP message to the CSMS, when a response message for the first OCPP message is received from the CSMS, it automatically transmits the second OCPP message defined in the order following the first OCPP message to the CSMS.

[0040] At this time, if the second OCPP message is not a message transmitted by the charger to the CSMS but a message transmitted by the CSMS to the charger, the test unit (116) waits for the reception of the second OCPP message. Then, when the second OCPP message is received, the third OCPP message, which is defined in the order following the second OCPP message and is a message transmitted by the charger to the CSMS, is automatically transmitted to the CSMS.

[0041] To explain in more detail through the scenario setting file shown in FIGS. 4a to 4c, the test unit (116) sends a data transfer request (DataTransfer.req) message, which is defined first in the scenario setting file, to the CSMS, and then, when a response message for the DataTransfer.req message is received from the CSMS, it automatically sends a status notification request (StatusNotification.req) message, which is defined in the next order, to the CSMS. Here, "getUnitPrice.req" in the messageId field of the DataTransfer.req message indicates that the message is a message requesting the price per unit in a charging session. Also, "status":"Available" in the payload field of the StatusNotification.req message indicates that the current status of the charger is 'available'.

[0042] Meanwhile, since the remote charging start request (RemoteStartTransaction.req) message defined in the scenario setting file as the next step after the StatusNotification.req message is a message sent by the CSMS to the charger rather than a message sent by the charger to the CSMS, the test unit (116) that sent the StatusNotification.req message to the CSMS waits for the reception of the RemoteStartTransaction.req message when it receives a response message for the StatusNotification.req message from the CSMS.

[0043] Subsequently, when the test unit (116) receives the RemoteStartTransaction.req message, it automatically sends the authentication request (Authorize.req) message, which is defined in the scenario configuration file as the next step after the RemoteStartTransaction.req message, to the CSMS. Here, "1010010015608979" in the idTag field of the Authorize.req message represents the user's identification tag.

[0044] Then, when the test unit (116) receives a response message for the Authorize.req message, it automatically sends the StatusNotification.req message, which is defined as the next sequence of the Authorize.req message in the scenario setting file, to the CSMS. Here, "status":"Preparing" in the payload field of the StatusNotification.req message indicates that the current status of the charger is preparing.

[0045] The test unit (116) that receives the response message of the above StatusNotification.req message automatically sends a charging start request (StartTransaction.req) message defined as the next order after the StatusNotification.req message in the scenario setting file to the CSMS, and when the response message for the above StartTransaction.req message is received from the CSMS, it automatically sends the StatusNotification.req message defined as the next order after the above StartTransaction.req message to the CSMS.

[0046] Subsequently, when the test unit (116) receives a response message for the StatusNotification.req message from the CSMS, it automatically sends a power meter measurement value report (MeterValues.req) message to the CSMS.

[0047] Meanwhile, since the remote charging stop request (RemoteStopTransaction.req) message defined in the scenario setting file in the order following the MeterValues.req message is a message sent by the CSMS to the charger rather than a message sent by the charger to the CSMS, the test unit (116) that sent the MeterValues.req message to the CSMS waits for the reception of the RemoteStopTransaction.req message when it receives a response message for the MeterValues.req message from the CSMS.

[0048] Subsequently, when the test unit (116) receives the RemoteStopTransaction.req message, it automatically sends the StopTransaction.req message, which is defined in the scenario setting file as the next step after the RemoteStopTransaction.req message, to the CSMS, and when the response message to the StopTransaction.req message is received, it automatically sends the StatusNotification.req message, which is defined in the scenario setting file as the next step after the StopTransaction.req message, to the CSMS. Here, "status":"Finishing" in the payload field of the StatusNotification.req message indicates that the current status of the charger is in the process of finishing.

[0049] Additionally, when the test unit (116) receives a response message for the StatusNotification.req message from the CSMS, it automatically sends the DataTransfer.req message, which is defined in the scenario setting file in the order following the StatusNotification.req message, to the CSMS. Here, "stopTransactionSubInfo.req" in the messageId field of the DataTransfer.req message indicates that the message contains additional information related to the termination of the charging session.

[0050] Finally, when the test unit (116) receives a response message for the DataTransfer.req message from the CSMS, it automatically sends the StatusNotification.req message, which is defined in the scenario setting file in the order following the DataTransfer.req message, to the CSMS.

[0051] FIG. 5 is a flowchart illustrating the operation of a test scenario driving device according to an embodiment of the present invention automatically transmitting an OCPP message.

[0052] The test scenario driving device receives a scenario setting file containing connection information between the charger and the CSMS and OCPP message information transmitted and received between the charger and the CSMS. (S501)

[0053] Then, the test scenario driving device generates a charger simulation model to simulate a virtual charger operating according to the scenario setting file input in S501, and establishes a connection between the charger simulation model and the CSMS according to the connection information of the scenario setting file. (S503) Here, the charger simulation model refers to a model that simulates the operation of a charger to simulate compatibility between the charger and the CSMS, and it is assumed here that it simulates the operation of a virtual charger operating according to the scenario setting file.

[0054] Subsequently, the test scenario driving device automatically transmits at least one OCPP message defined in the scenario setting file to the CSMS like a charger to test the charger simulation model. (S505)

[0055] The OCPP message automatic transmission method of the present invention as described above can be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc., either individually or in combination.

[0056] The program instructions recorded on the above-mentioned computer-readable recording medium may be those specifically designed and configured for the present invention, or they may be those known and available to those skilled in the art of computer software.

[0057] Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, and flash memory.

[0058] Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware device may be configured to operate as one or more software modules to perform processing according to the present invention, and vice versa.

[0059] Although various embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above. It is understood that various modifications can be made by those skilled in the art without departing from the essence of the invention as claimed in the claims, and such modifications should not be understood individually from the technical spirit or perspective of the present invention. Explanation of the symbols

[0061] 110: Test Scenario Driving Device 112: Input section 114: Connection Settings 116: Test section 130: CSMS

Claims

Claim 1 A method for automatically transmitting Open Charge Point Protocol (OCPP) messages in a test scenario driving device that simulates compatibility between at least one charger and a Charging Station Management System (CSMS), comprising: receiving a scenario setting file including connection information between the charger and the CSMS and OCPP message information transmitted and received between the charger and the CSMS; creating a charger simulation model to simulate a virtual charger operating according to the input scenario setting file, and establishing a connection between the charger simulation model and the CSMS according to the connection information of the scenario setting file; and automatically transmitting at least one OCPP message defined in the scenario setting file to the CSMS to test the charger simulation model; wherein the step of testing the charger simulation model includes transmitting the at least one OCPP message according to the order defined in the scenario setting file, and then transmitting a first OCPP message to the CSMS, and when a response message for the first OCPP message is received from the CSMS, automatically transmitting a second OCPP message defined in the order following the first OCPP message to the CSMS. Claim 2 delete Claim 3 A method for automatically transmitting an OCPP message according to claim 1, further comprising: a step of waiting for reception of the second OCPP message when the second OCPP message is a message transmitted by the CSMS to the charger, rather than a message transmitted by the charger to the CSMS; and a step of automatically transmitting a third OCPP message to the CSMS when the second OCPP message is received, which is defined in the order following the second OCPP message and is a message transmitted by the charger to the CSMS. Claim 4 A method for automatically transmitting OCPP messages according to claim 1, wherein the connection information includes a WebSocket URL for connection with the CSMS. Claim 5 A method for automatically transmitting an OCPP message according to claim 1, wherein the OCPP message information includes at least one of a message type, a unique message identifier, and data information transmitted through the message. Claim 6 A test scenario driving device for simulating compatibility between at least one charger and a Charging Station Management System (CSMS) by automatically transmitting Open Charge Point Protocol (OCPP) messages, comprising: an input unit receiving a scenario setting file including connection information between the charger and the CSMS and OCPP message information transmitted and received between the charger and the CSMS; a connection setting unit creating a charger simulation model to simulate a virtual charger operating according to the input scenario setting file and setting a connection between the charger simulation model and the CSMS according to the connection information of the scenario setting file; and a test unit automatically transmitting at least one OCPP message defined in the scenario setting file to the CSMS to test the charger simulation model, wherein the test unit transmits the at least one OCPP message according to the order defined in the scenario setting file, and after transmitting a first OCPP message to the CSMS, when a response message for the first OCPP message is received from the CSMS, automatically transmits a second OCPP message defined in the order following the first OCPP message to the CSMS. Claim 7 delete Claim 8 In claim 6, the test unit waits for reception of the second OCPP message when the second OCPP message is not a message transmitted by the charger to the CSMS but a message transmitted by the CSMS to the charger, and when the second OCPP message is received, automatically transmits a third OCPP message to the CSMS, which is defined in the order following the second OCPP message and is a message transmitted by the charger to the CSMS. Claim 9 In claim 6, the test scenario driving device, wherein the connection information includes a WebSocket URL for connection with the CSMS. Claim 10 A test scenario driving device according to claim 6, wherein the OCPP message information comprises at least one of a message type, a unique message identifier, and data information transmitted through the message.

Images