Method and device for bidirectional communication for hydrogen fueling

Abstract

This method for bidirectional communication for hydrogen fueling comprises the steps of: negotiating a communication protocol with a dispenser for fueling hydrogen mobility with hydrogen, the communication protocol being negotiated on the basis of interoperability or compatibility-related information checked in advance with the dispenser; negotiating a fueling protocol; negotiating a fueling parameter on the basis of the fueling protocol; and, after hydrogen fueling is started on the basis of the negotiated fueling protocol and the negotiated fueling parameter, monitoring the state of the hydrogen fueling via fueling loop request messages and fueling loop response messages.

Description

Hydrogen fuel supply two-way communication method and device

[0001] The present invention relates to a communication technology for handling hydrogen fueling from a hydrogen / refueling station or dispenser to hydrogen mobility, and more particularly, to a hydrogen fueling process capable of improving the safety, compatibility, efficiency, and reliability of hydrogen fueling, a two-way communication method for the hydrogen fueling process, and a device using the same.

[0002] The material described in this section merely provides background information for the present embodiment and does not constitute prior art.

[0003] Hydrogen mobility refers to mobility that uses hydrogen as an energy source or fuel to generate electricity and use it to drive an electric motor. Hydrogen mobility encompasses hydrogen cars, hydrogen-electric vehicles, industrial trucks, trains, ships, aircraft, and aerial mobility, and refers to all devices that use hydrogen as fuel to generate electricity and propel them. This type of hydrogen mobility is also called hydrogen-fueled mobility or hydrogen-powered mobility, and vehicles are typically categorized into hydrogen-electric vehicles and hydrogen-fueled vehicles.

[0004] Hydrogen fuel cell vehicles (FCEVs) are zero-emission vehicles that run on electricity generated by combining high-pressure hydrogen stored onboard with air. FCEVs are also known as hydrogen fuel cell vehicles, fuel cell electric vehicles (FCEVs), or simply hydrogen cars. Most FCEVs utilize a fuel cell system that uses hydrogen as its energy source to generate electricity, which then powers a motor. FCEVs not only emit only pure water (H2O) during the electricity generation process, but also have the ability to remove ultrafine dust from the atmosphere while in operation, attracting attention as a future eco-friendly form of mobility.

[0005] Hydrogen-fueled vehicles (HVs) use hydrogen as fuel. However, unlike FCEVs, they burn hydrogen directly in an internal combustion engine (ICE), generating heat to power the vehicle's electric motor. The hydrogen fueling method for HVs is not significantly different from that for FCEVs.

[0006] Hydrogen mobility, as mentioned above, is widely recognized as a technology with potential for use across industries, given the inexhaustible availability of hydrogen as a fuel and the environmentally friendly nature of the energy production process.

[0007] Meanwhile, to utilize hydrogen mobility, the vehicle or its user must refuel the vehicle's hydrogen tank at a hydrogen refueling station offering hydrogen refueling services and pay the hydrogen refueling fee. In particular, the hydrogen refueling process, control techniques, and protocols for these processes are being automated through computing technologies. In this era of automation, the importance of security in hydrogen refueling communications between hydrogen infrastructure and hydrogen mobility is increasing.

[0008] For example, in a general automated control technique for supplying hydrogen fuel to a vehicle that uses hydrogen as fuel, the ultimate goal is to control the temperature and pressure of a compressed hydrogen storage system (CHSS) under the limit temperature and limit pressure conditions of the CHSS for the safety of hydrogen fuel supply.

[0009] The conventional hydrogen fueling process, control techniques, and protocols for hydrogen fuel cell vehicles described above were developed at a time when wired and wireless communication technologies and control computing techniques were not yet mature. Consequently, they do not adequately reflect the advancements in recent information and communications technology (ICT). Therefore, conventional hydrogen fueling technologies for hydrogen fuel cell vehicles are inefficient, slow, and unsuitable for large-scale hydrogen fueling.

[0010] In particular, in the case of wireless hydrogen fueling communication, most hydrogen fueling control devices utilize unidirectional infrared communication devices. Therefore, conventional wireless hydrogen fueling communication still suffers from the limitations and vulnerabilities of unidirectional communication. Therefore, a new method for hydrogen fueling communication is currently required.

[0011] The present invention has been derived to solve the problems of the prior art as described above, and the purpose of the present invention is to provide a hydrogen fueling two-way communication method and device that can overcome the limitations and vulnerabilities of existing one-way communication in the hydrogen fueling process of hydrogen mobility or the communication protocol for the hydrogen fueling process and improve the safety, compatibility, efficiency, and reliability of hydrogen fueling.

[0012] Another object of the present invention is to provide a hydrogen fueling two-way communication method and device that enables hydrogen mobility and dispensers to select a legacy communication medium or an advanced communication medium to effectively achieve a hydrogen fueling goal.

[0013] Another object of the present invention is to provide a hydrogen fueling two-way communication method and device capable of handling errors and / or emergency situations occurring during communication protocol negotiation, fueling protocol negotiation, fueling parameter negotiation, safety check-in, monitoring and control, safety check-out, and termination for the hydrogen fueling process.

[0014] According to one embodiment of the present invention for achieving the above object, a hydrogen fueling two-way communication method is provided, which is a hydrogen fueling two-way communication method performed by hydrogen mobility, comprising: a step of negotiating a communication protocol for a process in which the dispenser fuels hydrogen to the mobility based on interoperability or compatibility-related information confirmed in advance with a dispenser that fuels hydrogen to the hydrogen mobility; a step of negotiating fueling protocols for hydrogen fueling with the dispenser; a step of negotiating fueling parameters with the dispenser based on the fueling protocol negotiated with the dispenser; and a step of monitoring the start of the hydrogen fueling and the status of the hydrogen fueling based on the negotiated fueling protocol and the negotiated fueling parameters through a fueling loop request message and a fueling loop response message.

[0015] In the above monitoring step, the fuel supply loop request message includes a field for the current operation and a field indicating the reason for the operation. Here, the hydrogen fuel supply is started according to the preset information in the field for the operation.

[0016] In the above monitoring step, the fuel supply loop response message includes fields indicating the status, reason, and result of the current operation. Here, the field indicating the status includes information indicating that the current status is fuel supplying, and the field indicating the result includes information indicating that the monitoring result or control status is normal.

[0017] The monitoring step may include transmitting a message including information about the fueling loop of the hydrogen mobility itself to the dispenser, and receiving a message from the dispenser including information about the fueling loop of the dispenser itself corresponding to the fueling loop of the mobility.

[0018] The above monitoring step may include a step of transmitting a fuel supply control request message including information for slowing down the fuel supply or reducing the unit fuel supply amount to the dispenser, and receiving a response message including information indicating a decrease in the fuel supply status or a decrease in speed from the dispenser.

[0019] The above monitoring step may include a step of transmitting a fuel supply control request message requesting to stop fuel supply to the dispenser, and receiving a fuel supply status response message including information on stopping / stopping fuel supply from the dispenser.

[0020] The monitoring step may include transmitting information or parameters regarding the current tank temperature and current tank pressure of the hydrogen mobility to the dispenser, and receiving parameters related to at least one of fuel supply start, stop, ramping up, ramping down, and current injection pressure from the dispenser.

[0021] The above monitoring step may include a step of transmitting information or parameters regarding start, pause, resume, or terminate of fuel supply to the dispenser.

[0022] The monitoring step may include receiving, from the dispenser, a reporting-related message including information or parameters regarding status information, current ambient temperature, current pressure ramp rate, deliver fuel flow rate, current fuel delivery temperature, pre-cooling temperature, current fuel delivery pressure, whether a cooled dispenser is in use, whether a fallback is in use, reason for fuel delivery stoppage, and the amount of hydrogen currently being fueled.

[0023] The monitoring step may include information or parameters from the dispenser regarding a target final tank pressure, a target final tank temperature, a target fuel supply average pressure rise rate, a target fuel charge amount, a current fuel charge amount, and an estimated remaining duration.

[0024] The above monitoring step may include a step of transmitting the fuel supply loop request message to the dispenser within a message sequence setting time after receiving a fuel supply parameter negotiation response message from the dispenser, when TCP is used in the monitoring and control procedure, or when the safety check-in procedure by the safety check-in response message or the fuel supply protocol is omitted.

[0025] In the above monitoring step, the fuel supply loop request message or the fuel supply loop response message is a TLS (transport layer security) message or a DTLS (datagram transmission layer security) message.

[0026] The above hydrogen fuel supply two-way communication method may further include a step of transmitting information for controlling parameters including a pressure increase rate or an average pressure increase rate to the dispenser to control the fuel supply speed in the hydrogen fuel supply.

[0027] The above hydrogen fuel supply two-way communication method may further include a step of detecting an error occurring during a communication process of preparing the hydrogen fuel supply or during a process of the dispenser performing hydrogen fuel supply to the hydrogen mobility.

[0028] The above detected errors can be classified as safety-critical errors or non-safety-critical errors.

[0029] The above hydrogen fuel supply two-way communication method may further include a step of determining whether to stop the communication process or the hydrogen fuel supply process based on the detected error; and a step of transmitting a message including whether to stop the communication process or the hydrogen fuel supply process to the dispenser.

[0030] The above hydrogen fuel supply two-way communication method may further include a step of performing an error handling procedure when the detected error is not a safety-critical error.

[0031] The step of performing the above error handling procedure may include a step of classifying the detected error into at least one of a communication error, a system error, and a qualitative error.

[0032] The above hydrogen fuel supply two-way communication method may further include a step of determining whether to replace the first fuel supply protocol of the communication process or the process of performing the hydrogen fuel supply with a fallback second fuel supply protocol if the detected error is not a safety-critical error.

[0033] The above hydrogen fuel supply two-way communication method may further include a step of performing an emergency handling procedure when the detected error is a safety-critical error.

[0034] The above hydrogen fuel supply two-way communication method may further include a step of transmitting a safety check-in request message to the dispenser within a message sequence setting time after receiving a fuel supply parameter negotiation response message from the dispenser through fuel supply parameter negotiation.

[0035] The above hydrogen fuel supply two-way communication method may further include a step of checking whether the nozzle and receptacle are fixed or leaking through a safety check-in step including transmitting the safety check-in request message.

[0036] The above hydrogen fuel supply two-way communication method may include, in a safety check-in step starting with transmission of the safety check-in request message, a step of reporting parameters regarding the current status or immobilization status of the mobility itself to the dispenser, and receiving parameters regarding a coupler lock status, a leak check status, or a predicted mobility tank capacity from the dispenser.

[0037] The above hydrogen fuel supply two-way communication method may further include the steps of: receiving a fuel supply loop response message from the dispenser in which the "result" is set to "OK", the "status" is set to "finished", or the prefix is ​​"stopped"; transmitting a message including information on a coupler check result to the dispenser and receiving a message including information indicating that a coupler check is in progress from the dispenser; and transmitting a message including the coupler check result information to the dispenser and receiving a message including coupler check completion information from the dispenser.

[0038] The above hydrogen fuel supply two-way communication method may further include, after receiving the fuel supply loop response message, a step of receiving a report message from the dispenser, including information or parameters regarding a coupler release status. The information regarding the coupler release status may include information regarding locked, unlocked, icing, or a problem.

[0039] According to another embodiment of the present invention for achieving the above object, a hydrogen fueling two-way communication method is provided, which is performed by a dispenser that supplies hydrogen to hydrogen mobility or a hydrogen charging station equipped with the dispenser, and which comprises the steps of: negotiating a communication protocol for a process of supplying hydrogen to the mobility with the hydrogen mobility based on interoperability or compatibility-related information previously confirmed with the hydrogen mobility; negotiating fueling protocols for hydrogen fueling with the hydrogen mobility; negotiating fueling parameters with the hydrogen mobility based on the fueling protocol negotiated with the hydrogen mobility; and monitoring the start of the hydrogen fueling and the state of the hydrogen fueling through a fueling loop request message and a fueling loop response message based on the negotiated fueling protocol and the negotiated fueling parameters.

[0040] In the above monitoring step, the fuel supply loop request message may include a field for the current operation and optionally include a field indicating the reason for the operation. Here, the hydrogen fuel supply may be started according to preset information in the field for the operation.

[0041] In the above monitoring step, the fuel supply loop response message may include fields indicating the status and result of the current operation. Here, the field indicating the status may include information indicating that the current status is fuel supplying, and the field indicating the result may include information indicating that the monitoring result or control status is normal.

[0042] The monitoring step may include receiving a message from the hydrogen mobility including information about a fueling loop of the hydrogen mobility, and transmitting a message including information about a fueling loop of the dispenser corresponding to the fueling loop of the mobility to the hydrogen mobility.

[0043] The above monitoring step may include receiving a fuel supply control request message including information for slowing down fuel supply or reducing the unit fuel supply amount from the hydrogen mobility, and transmitting a response message including information indicating a decrease in the fuel supply status or a decrease in speed to the hydrogen mobility.

[0044] The above monitoring step may include a step of receiving a fuel supply control request message requesting to stop fuel supply from the hydrogen mobility, and transmitting a fuel supply status response message including information on stopping or stopping fuel supply to the hydrogen mobility.

[0045] The monitoring step may include receiving information or parameters about the current tank temperature and current tank pressure of the hydrogen mobility from the hydrogen mobility, and transmitting parameters related to at least one of starting, stopping, ramping up, ramping down, and current injection pressure of fuel supply to the hydrogen mobility.

[0046] The above monitoring step may include a step of receiving information or parameters regarding start, pause, resume, or termination of fuel supply from the hydrogen mobility.

[0047] The monitoring step may include a step of transmitting a reporting-related message including information or parameters regarding at least one of status information, current ambient temperature, current pressure ramp rate, deliver fuel flow rate, current fuel delivery temperature, pre-cooling temperature, current fuel delivery pressure, whether a cooling dispenser is in use, whether a fallback is in use, reason for fueling stop, and current supply amount of hydrogen supplied to the hydrogen mobility.

[0048] The monitoring step may include transmitting a reporting-related message including information or parameters regarding at least one of a target final tank pressure, a target final tank temperature, a target fuel supply average pressure rise rate, a target fuel charge amount, a current fuel charge amount, and an estimated remaining duration to the hydrogen mobility.

[0049] The above monitoring step may include a step of receiving the fuel supply loop request message from the hydrogen mobility within a message sequence setting time after transmitting a fuel supply parameter negotiation response message to the hydrogen mobility when TCP is used in the monitoring and control procedure, or when the safety check-in response message or the safety check-in procedure by the fuel supply protocol is omitted.

[0050] In the above monitoring step, the fuel supply loop request message or the fuel supply loop response message may be a TLS (transport layer security) message or a DTLS (datagram transmission layer security) message.

[0051] The above hydrogen fuel supply two-way communication method may further include a step of controlling a parameter including a pressure increase rate or an average pressure increase rate to control a fuel supply speed in the hydrogen fuel supply.

[0052] The above-described two-way hydrogen fuel supply communication method may further include a step of detecting an error occurring during the communication process of preparing the hydrogen fuel supply or during the process of the dispenser supplying hydrogen fuel to the hydrogen mobility. The detected error may be classified as a safety-critical error or a non-safety-critical error.

[0053] The above hydrogen fuel supply two-way communication method may further include a step of receiving a message including information or parameters for determining whether to stop the communication process or the hydrogen fuel supply process based on the detected error from the hydrogen mobility.

[0054] The above-described two-way hydrogen fuel supply communication method may further include a step of performing an error handling procedure if the detected error is not critical to safety. Here, the step of performing the error handling procedure may include a step of classifying the detected error into at least one of a communication error, a system error, and a qualitative error.

[0055] The above hydrogen fuel supply two-way communication method may further include a step of determining whether to replace the first fuel supply protocol of the communication process or the process of performing the hydrogen fuel supply with a fallback second fuel supply protocol if the detected error is not a safety-critical error.

[0056] The above hydrogen fuel supply two-way communication method may further include a step of performing an emergency handling procedure when the detected error is a safety-critical error.

[0057] The above hydrogen fuel supply two-way communication method may further include a step of receiving a safety check-in request message from the hydrogen mobility within a message sequence setting time after transmitting a fuel supply parameter negotiation response message through fuel supply parameter negotiation to the hydrogen mobility.

[0058] The above hydrogen fuel supply two-way communication method may further include a step of checking whether the nozzle and receptacle are fixed or leaking through a safety check-in step including transmitting the safety check-in request message.

[0059] The above hydrogen fuel supply two-way communication method may include, in a safety check-in step starting with transmission of the safety check-in request message, a step of receiving parameters regarding the current status or immobilization status of the hydrogen mobility from the hydrogen mobility, and transmitting parameters regarding a coupler lock status, a leak check status, or a predicted mobility tank capacity to the hydrogen mobility.

[0060] The above hydrogen fuel supply two-way communication method may further include the steps of transmitting a fuel supply loop response message to the hydrogen mobility in which the "result" is set to "OK", the "status" is set to "finished", or the prefix is ​​"stopped"; receiving a message including information on a coupler check result from the hydrogen mobility and transmitting a message including information indicating that a coupler check is in progress to the hydrogen mobility; and receiving a message including information on the coupler check result from the hydrogen mobility and transmitting a message including information indicating that a coupler check is being performed to the hydrogen mobility.

[0061] The above hydrogen fuel supply two-way communication method may further include, after the step of transmitting the fuel supply loop response message, the step of transmitting a report message including information or parameters regarding the coupler release status to the hydrogen mobility. The information regarding the coupler release status may include information regarding locked, unlocked, icing, or a problem.

[0062] In order to achieve the above object, according to another embodiment of the present invention, a hydrogen fueling two-way communication device is provided for hydrogen mobility, comprising: a memory storing at least one command; and a processor executing the at least one command, wherein the processor, based on interoperability or compatibility-related information previously confirmed with a dispenser that fuels hydrogen to hydrogen mobility, negotiates a communication protocol for a process in which the dispenser fuels hydrogen to the mobility; negotiates fueling protocols for hydrogen fueling with the dispenser; and negotiates fueling parameters with the dispenser based on the fueling protocol negotiated with the dispenser. And is configured to perform a step of monitoring the start of the hydrogen fuel supply and the status of the hydrogen fuel supply based on the negotiated fuel supply protocol and the negotiated fuel supply parameters through a fueling loop request message and a fueling loop response message.

[0063] The above fuel supply loop request message includes a field for the current operation and a field indicating the reason for the operation. Here, the hydrogen fuel supply is initiated according to the preset information in the field for the operation.

[0064] The above fuel supply loop response message includes fields indicating the status, reason, and result of the current operation. Here, the field indicating the status includes information indicating that the current state is fuel supplying, and the field indicating the result includes information indicating that the monitoring result or control state is normal.

[0065] The processor may further perform the steps of: detecting an error occurring during a communication process for preparing the hydrogen fuel supply or during a process in which the dispenser performs hydrogen fuel supply to the hydrogen mobility; determining whether to stop the communication process or the process for performing the hydrogen fuel supply based on the detected error; performing an error handling procedure when the detected error is not a safety-critical error; and performing an emergency handling procedure when the detected error is a safety-critical error.

[0066] Here, in the step of detecting the error or the step of determining, the detected error is classified as a safety-critical error or a non-safety-critical error.

[0067] The step of performing the above error handling procedure may be configured to classify the detected error as at least one of a communication error, a system error, and a qualitative error when the detected error is not a safety-critical error.

[0068] The step of performing the above error handling procedure may further include a step of determining whether to replace the first fuel supply protocol of the communication process or the hydrogen fuel supply process with a fallbacked second fuel supply protocol when the detected error is not a safety-critical error.

[0069] According to the above-described hydrogen fueling two-way communication method and device, the limitations and vulnerabilities of existing one-way communication in the hydrogen fueling process of hydrogen mobility and the communication protocol therefor can be overcome, and the safety, compatibility, efficiency, and reliability of hydrogen charging can be improved.

[0070] In addition, according to the present invention, rules for communication protocol negotiation, fuel supply protocol negotiation, and fuel supply parameter negotiation and communication protocol fallback for hydrogen charging can be provided, which select a communication protocol required for executing a protocol for hydrogen charging according to a use case while considering priorities according to the preferences of hydrogen mobility and the dispenser, while maximizing interoperability between the hydrogen mobility and the dispenser and considering backward compatibility.

[0071] In addition, according to the present invention, rules and procedures necessary for communication protocol negotiation, fueling protocol negotiation, and fueling parameter negotiation can be provided so that hydrogen mobility and a dispenser can cooperate to effectively determine a conventional communication medium or an advanced communication medium to effectively achieve a hydrogen fueling goal.

[0072] FIG. 1 is a conceptual diagram of a hydrogen fuel supply system including hydrogen mobility to which a hydrogen fuel supply two-way communication method according to one embodiment of the present invention can be applied.

[0073] FIG. 2 is a partially enlarged view illustrating the physical connection structure between a fuel cell electric vehicle (FCEV) and a dispenser in the hydrogen fuel supply system of FIG. 1.

[0074] FIG. 3 is a conceptual diagram for explaining a hydrogen fuel supply control process applicable to the hydrogen fuel supply system of FIG. 1.

[0075] Figure 4 is a graph illustrating changes in the state of hydrogen fuel that occur during the hydrogen fuel supply control process of Figure 3.

[0076] FIG. 5 is an exemplary diagram showing a framework for functional blocks of a hydrogen fuel supply procedure to which a hydrogen fuel supply two-way communication method according to one embodiment of the present invention can be applied.

[0077] FIG. 6 is an exemplary diagram showing a communication stack related to each use case of FIG. 5 to which a hydrogen fuel supply two-way communication method according to an embodiment of the present invention can be applied, based on the OSI (open systems interconnection) 7 layer, which is a reference model.

[0078] Figure 7 is an example diagram showing a JSON (Javascript object notation) message format that can be applied to the presentation layer or session layer among the communication stacks of Figure 6.

[0079] FIG. 8 is an exemplary diagram for explaining a communication protocol negotiation procedure among the functional blocks of the hydrogen fuel supply procedure of FIG. 5 (hereinafter simply referred to as the “fuel supply framework”) and a communication protocol negotiation request message applicable to the functional blocks.

[0080] Figure 9 is an example diagram showing the JSON message format of the communication protocol negotiation request message of Figure 8.

[0081] FIG. 10 is an example diagram for explaining a communication protocol negotiation response message in a communication protocol negotiation procedure applicable to the fuel supply framework of FIG. 5 and its functional blocks.

[0082] Figure 11 is an example diagram showing the JSON message format of the communication protocol negotiation request message of Figure 10.

[0083] FIG. 12 is an example diagram for explaining the fueling protocol negotiation procedure of the fueling framework of FIG. 5 and a fueling protocol negotiation request message applicable to its functional block.

[0084] Figure 13 is an example diagram showing the JSON message format of the fuel supply protocol negotiation request message of Figure 12.

[0085] FIG. 14 is an example diagram for explaining the fuel supply protocol negotiation procedure of the fuel supply framework of FIG. 5 and the fuel supply protocol negotiation response message applicable to its functional block.

[0086] Figure 15 is an example diagram showing the JSON message format of the fuel supply protocol negotiation response message of Figure 14.

[0087] FIG. 16 is an example diagram for explaining the fueling parameter negotiation procedure of the fueling framework of FIG. 5 and the fueling parameter negotiation request message applicable to its functional block.

[0088] FIG. 17 is an example diagram for explaining the fuel supply parameter negotiation procedure of the fuel supply framework of FIG. 5 and the fuel supply parameter negotiation response message applicable to its functional block.

[0089] FIG. 18 is an example diagram showing the JSON message format of the fuel supply parameter negotiation request message of FIG. 16 or the fuel supply parameter negotiation response message of FIG. 17.

[0090] FIG. 19 is an example diagram for explaining the safety check-in procedure of the fuel supply framework of FIG. 5 and a safety check-in request message applicable to its functional blocks.

[0091] FIG. 20 is an example diagram for explaining the safety check-in procedure of the fuel supply framework of FIG. 5 and the safety check-in response message applicable to its functional blocks.

[0092] FIG. 21 is an example diagram illustrating the monitoring and control procedure of the fuel supply framework of FIG. 5 and the monitoring and control request message applicable to its functional blocks.

[0093] Figure 22 is an example diagram showing the JSON message format of the monitoring and control request message of Figure 21.

[0094] FIG. 23 is an example diagram illustrating the monitoring and control procedure of the fuel supply framework of FIG. 5 and the monitoring and control response messages applicable to its functional blocks.

[0095] Figure 24 is an example diagram showing the JSON message format of the monitoring and control response message of Figure 23.

[0096] FIG. 25 is an example diagram for explaining the safety check-out procedure of the fuel supply framework of FIG. 5 and a safety check-out request message applicable to its functional block.

[0097] FIG. 26 is an example diagram for explaining the safe checkout procedure of the fuel supply framework of FIG. 5 and the safe checkout response message applicable to its functional block.

[0098] FIG. 27 is an example diagram for explaining the termination procedure of the fuel supply framework of FIG. 5 and the termination request message applicable to its functional block.

[0099] Figure 28 is an example diagram showing the JSON message format of the termination request message of Figure 27.

[0100] FIG. 29 is an example diagram for explaining the termination procedure of the fuel supply framework of FIG. 5 and the termination response message applicable to its functional block.

[0101] Figure 30 is an example diagram showing the JSON message format of the termination response message of Figure 29.

[0102] Figure 31 is an example diagram showing the error handling procedure of the fuel supply framework of Figure 5 and the JSON message format of an error handling message that can be applied to its functional block.

[0103] Figure 32 is an example diagram showing the emergency handling procedure of the fuel supply framework of Figure 5 and the JSON message format of an emergency handling message that can be applied to its function block.

[0104] Figure 33 is a framework for functional blocks of a hydrogen fuel supply procedure to which a hydrogen fuel supply two-way communication method according to another embodiment of the present invention can be applied.

[0105] FIG. 34 is a conceptual block diagram of a computing system applicable to a hydrogen fuel supply communication device according to another embodiment of the present invention.

[0106] Figure 35 is a block diagram illustrating a software module of a hydrogen fuel supply communication device that can be additionally employed in the computing system of Figure 34.

[0107] In addition to the above purpose, other objects and features of the present invention will become apparent through the description of embodiments with reference to the attached drawings.

[0108] The present invention is susceptible to various modifications and embodiments. Specific embodiments are illustrated and described in detail in the drawings. However, this is not intended to limit the present invention to specific embodiments, but rather to encompass all modifications, equivalents, and alternatives falling within the spirit and technical scope of the present invention.

[0109] Terms such as "first," "second," "A," and "B" may be used to describe various components, but these components should not be limited by these terms. These terms are used solely to distinguish one component from another. For example, without departing from the scope of the present invention, the first component could be referred to as the "second component," and similarly, the second component could also be referred to as the "first component." The term "and / or" includes any combination of multiple related items listed or any one of multiple related items listed.

[0110] In the embodiments of the present application, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.” Furthermore, in the embodiments of the present application, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.”

[0111] When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0112] The terminology used in this application is only used to describe specific embodiments and is not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this application, it should be understood that the terms "comprise" or "have" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not exclude in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0113] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and will not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0114] Some terms used in this specification are defined as follows:

[0115] A hydrogen-fueled vehicle, in a broad sense, can include both fuel cell electric vehicles (FCEVs) that utilize fuel cells, as well as internal combustion engine (ICE)-based vehicles that directly use hydrogen as fuel. In this specification, a hydrogen-fueled vehicle may also be referred to as a hydrogen electric vehicle or simply a hydrogen car.

[0116] Hydrogen mobility may include hydrogen-fueled mobility, which uses hydrogen as an energy source or fuel to generate electric energy and use it to drive a motor. In addition to hydrogen cars, hydrogen mobility may include industrial trucks, trains, ships, aircraft, aerial mobility, or devices that generate electric energy using hydrogen as fuel and use it to drive a motor. Furthermore, hydrogen mobility may include conventional automobiles, automobiles, and hybrid vehicles that use both human power and hydrogen fuel. In the embodiments below, hydrogen mobility may employ a hydrogen fueling protocol and / or a communication protocol for hydrogen fueling.

[0117] A compressed hydrogen storage system (CHSS) is a device that compresses and stores liquid hydrogen fuel, i.e., gaseous hydrogen or liquid hydrogen, as part of a vehicle / mobility system. Specifically, the hydrogen fuel may include at least one of gaseous hydrogen and liquid hydrogen, and may essentially mean compressed hydrogen, but is not limited thereto.

[0118] A pressure relief device (PRD) is placed in the CHSS and is capable of isolating the stored hydrogen from the rest of the fuel system and environment, or, conversely, releasing the hydrogen to the outside.

[0119] The pressure ramp rate (PRR) refers to the rate of increase in hydrogen pressure in a CHSS and can be expressed in MPa / min. The average pressure ramp rate (APRR or APR) can refer to the average value of the pressure ramp rate from the beginning to the end of hydrogen fueling.

[0120] Pre-cooling refers to the process of pre-cooling hydrogen gas at a hydrogen charging station before charging it into an electric vehicle or other vehicle. A dispenser is a component that delivers pre-cooled hydrogen to a CHSS. The dispenser is located at a hydrogen charging station and can perform hydrogen charging operations between the station's hydrogen storage tank and the vehicle's CHSS. A nozzle is a device connected to the dispenser and connected to the receptacle of a hydrogen electric vehicle, allowing the delivery of hydrogen fuel.

[0121] The aforementioned hydrogen charging basically refers to the process of supplying high-pressure hydrogen from a dispenser at a gas station or hydrogen station and compressing and storing it in the vehicle's fuel tank. Hydrogen charging can be used interchangeably with fueling in the context of supplying hydrogen fuel to a hydrogen electric vehicle. That is, in this specification, "fueling" can refer to fuel supply or charging, and "charging" can refer to the charging of hydrogen fuel. For example, a fueling protocol can be referred to as a charging protocol, a fueling session can be referred to as a charging session, and a fueling method can be referred to as a hydrogen charging method or a charging (fueling) method.

[0122] A fueling session may be used to mean communication sessions that occur across use cases for hydrogen fueling.

[0123] Interoperability can refer to the state in which components of a system can work together to achieve the intended function of the entire system. Information interoperability can refer to the ability of two or more networks, systems, devices, applications, or components to share information securely and effectively and easily with little or no user inconvenience.

[0124] Correlation / Association may include the process of establishing a relationship between two peer communication entities.

[0125] Command and control communication may refer to communication between an electric vehicle hydrogen fueling device and a hydrogen electric vehicle that exchanges information necessary for starting, controlling, and terminating the hydrogen fueling process.

[0126] In the context of Transport Layer Security (TLS), a client can refer to an endpoint that initiates a TLS connection. A connection can refer to a transport-layer connection between two endpoints. An endpoint is either the client or the server of the connection. A handshake is the initial negotiation between the client and server that establishes the parameters of subsequent interactions within TLS.

[0127] Additionally, in TLS-related terms, "peer" can refer to an endpoint. That is, when discussing a specific endpoint, "peer" refers to the endpoint, not the primary subject of discussion. A receiver is an endpoint that receives records. A sender is an endpoint that transmits records. And a server can be an endpoint that did not initiate a TLS connection.

[0128] While the detailed description below illustrates embodiments related to hydrogen fuel cell electric vehicles (FCEVs) or fuel cell electric vehicles (FCEVs), it will be apparent to those skilled in the art that the principles of the present invention can be applied to various types of hydrogen mobility. Furthermore, the two-way communication process for hydrogen charging of the present invention can be partially applied not only to hydrogen fuel mobility but also to buildings or facilities that use hydrogen as an energy source.

[0129] In the specification below, some or all of the communication procedures performed in hydrogen mobility, such as communication protocol negotiation, fuel supply protocol negotiation, and fuel supply parameter negotiation, may be performed by an electric control unit (ECU), a communication device, or a communication control device within the hydrogen mobility.

[0130] Additionally, some or all of the communication procedures, such as communication protocol negotiation, fuel supply protocol negotiation, and fuel supply parameter negotiation, performed in the dispenser may be performed by a controller, an electronic control unit, a communication device, or a communication control device of the dispenser. Additionally, some of the steps of the above method may be performed by a controller, an electronic control unit, a communication device, or a communication control device of a charging station associated with the dispenser.

[0131] Meanwhile, even if a technology was known prior to the filing date of the present invention, it may be included as a part of the composition of the present invention if necessary, and this will be described in this specification to the extent that it does not obscure the spirit of the present invention. However, in explaining the composition of the present invention, a detailed description of matters that were known prior to the filing date of the present invention and that could be clearly understood by those skilled in the art may obscure the spirit of the present invention, and therefore, an excessively detailed description of the known technology will be omitted. In addition, the spirit of the present invention is not to claim any rights to these known technologies, and the contents of the known technologies may be included as a part of the present invention to the extent that they do not deviate from the spirit of the present invention.

[0132] For example, in the case of one-way communication, infrared data association (IrDA) technology may be used, and in the case of two-way communication, short-range wireless communication technologies such as Bluetooth, wireless local area network (WLAN), and ultra-wideband (UWB) may be used, and wired communication technologies for one-way / two-way communication may be used, and technologies known prior to the filing of the present invention may be used, and at least some of these known technologies may be applied as element technologies necessary for implementing the present invention.

[0133] Hereinafter, a preferred embodiment according to the present invention will be described in detail with reference to the attached drawings.

[0134] FIG. 1 is a conceptual diagram of a hydrogen fuel supply system to which a two-way communication method for hydrogen fuel supply according to an embodiment of the present invention can be applied. FIG. 2 is a partially enlarged view illustrating a physical connection structure between a fuel cell electric vehicle (FCEV) and a dispenser in the hydrogen fuel supply system of FIG. 1. FIG. 3 is a conceptual diagram illustrating a hydrogen fuel supply control process applicable to the hydrogen fuel supply system of FIG. 1. And FIG. 4 is a graph illustrating changes in the state of hydrogen fuel that appear in the hydrogen fuel supply control process of FIG. 3.

[0135] Referring to FIGS. 1 to 3, the hydrogen fuel supply system may have a form including a hydrogen electric vehicle (100), a dispenser (200), and a hydrogen charging station (300). In the hydrogen fuel supply system, the dispenser (200) may be included in the hydrogen charging station (300) in a broad sense, and in that case, the hydrogen charging station may be referred to by a separate reference numeral (300A).

[0136] A hydrogen electric vehicle (100) may be equipped with an electronic control device (110), a vehicle system (120), a vehicle tank (130), and a receptacle (150) for hydrogen charging in addition to the basic mechanical devices, mechanical devices, electrical devices, electronic devices, and communication devices required for the vehicle.

[0137] In a hydrogen electric vehicle (100), the electronic control unit (110) may be configured to transmit and receive signals and data wired or wirelessly with the electronic control unit (210) of the hydrogen charging station (300) or the dispenser (300) to receive hydrogen fuel supply from the dispenser (200), and process the signals and data to control at least a part of the hydrogen fuel supply process from the dispenser (200). The electronic control unit (110) may be configured as at least a part of another electronic control unit mounted on the vehicle, or vice versa, and may be referred to as a first electronic control unit.

[0138] The vehicle system (120) may be connected to the first electronic control unit (110) and configured to charge or discharge hydrogen into or from the vehicle tank (130) according to a signal or command from the first electronic control unit (110) and monitor the status of the vehicle tank (130). Depending on the implementation, the vehicle system (120) may include or be configured to be coupled with a component that controls the operation of the fuel cell system or performs such control operations. This vehicle system (120) may also perform a vehicle safety function, in which case it may also be referred to as a vehicle safety system.

[0139] At least one or more vehicle tanks (130) may be provided, and preferably two may be provided. The vehicle tank (130) may store compressed hydrogen supplied from the hydrogen charging station (300) under the control of the vehicle system (120) and release the stored hydrogen. This vehicle tank (130) may correspond to at least a portion of a hydrogen storage system (140) attached to the vehicle.

[0140] The hydrogen storage system (140) may include a high-pressure hydrogen tank, a pressure control device, high-pressure pipes, and an external frame. The high-pressure hydrogen tank may have a capacity of tens to hundreds of liters. For use in a vehicle, the high-pressure hydrogen tank may be configured by connecting two small storage tanks in parallel. The high-pressure hydrogen tank may be coupled with a boss unit capable of controlling the inflow and outflow of hydrogen gas, and the charging and discharging of hydrogen gas may be controlled through the boss unit. The boss unit may be equipped with a valve, a pressure reducing device, and sensors for various measurements. The high-pressure hydrogen tank may correspond to the vehicle tank (130). The hydrogen storage system (140) may be referred to as a compressed hydrogen storage system (CHSS).

[0141] The hydrogen electric vehicle (100) described above may be equipped with a fuel cell system including a fuel cell stack, but is not limited thereto. The hydrogen electric vehicle (100) may be referred to as hydrogen fueled mobility or simply hydrogen mobility. In addition, for convenience of explanation, it may also be referred to simply as 'FCEV', 'vehicle', or 'mobility'. In the following specification, the object simply referred to as vehicle or mobility may be understood to include a hydrogen fueled vehicle or hydrogen fueled mobility that uses hydrogen as fuel in addition to the hydrogen electric vehicle (100).

[0142] A hydrogen charging station (300) may be equipped with a dispenser (200), an electronic control unit (210), a charging station system (220), a hydrogen tank (230), a station box (240), and a nozzle (250). The electronic control unit (210) may be referred to as a second electronic control unit. In addition, the hydrogen charging station (300) may further be equipped with a pre-cooler (280).

[0143] The dispenser (200) can supply hydrogen supplied from a hydrogen tank (230) to a vehicle through a nozzle (250) rigidly connected to a receptacle (150) of the vehicle under the control of a charging station system (220). The dispenser (200) may have an electronic control device (210) inside its housing, but is not limited thereto. The nozzle (250) can basically be installed at the end of a fuel supply cable that extends a certain length outside the housing of the dispenser (200).

[0144] The electronic control unit (210) transmits and receives signals and data to and from the first electronic control unit (110) of the vehicle via wire or wirelessly to perform a hydrogen fuel supply procedure from the dispenser (200) to the hydrogen electric vehicle (100), processes the signals and data, and controls the hydrogen fuel supply procedure at the hydrogen charging station. The electronic control unit (210) can exchange preset signals and data with the charging station system (220). The electronic control unit (210) may be referred to as a second electronic control unit.

[0145] In addition, the dispenser (200) or the second electronic control device (210) may be equipped with at least one controller or charging control logic for hydrogen fuel supply. The at least one controller or charging control logic may be used to control the hydrogen fueling process by utilizing status information such as temperature and pressure of hydrogen fuel supplied from the dispenser (200) to the vehicle (100) or charged into the vehicle tank (130), and charging status information such as the state of charge (SOC, State of Charge) of the CHSS.

[0146] The electronic control device (210) described above may be a communication entity related to the dispenser (200) that communicates with the vehicle (100), or may be a separate communication device mounted on the dispenser (200). In addition, the electronic control device (210) is not limited to an electronic control device within the charging station system (220), and may include a communication entity that has entered the communication area of ​​the hydrogen charging station (300) and has access to the charging station system (220) or acquired control authority.

[0147] Each of the first electronic control unit (110) and the second electronic control unit (210) described above may be composed of multiple electronic control units, and may be configured to match and operate different electronic control units for each communication protocol. In this case, it may be useful when falling back for backward compatibility and when two-way communication cannot be used and one-way communication must be used. In addition, it may be useful when the first electronic control unit (110) and the second electronic control unit (210) combine and utilize different communication methods in multiple stages of the hydrogen fueling procedure, such as when using WiFi during actual charging after pairing using NFC (near field communication).

[0148] The charging station system (220) can monitor or control the pressure, speed, and temperature of hydrogen discharged from the hydrogen tank (230) based on signals and / or data from the second electronic control unit (210). To this end, the charging station system (220) can control the operation of the station box (240) connected to the discharge port or discharge valve of the hydrogen tank (230). The charging station system (220) may also be referred to as a charging station safety system.

[0149] The hydrogen tank (230) stores hydrogen or compressed hydrogen. The hydrogen tank (230) can operate to store hydrogen or compressed hydrogen and release the stored hydrogen at a predetermined pressure or flow rate under the control of a predetermined component of the charging station system (220), such as a safety management module. The hydrogen tank (230) may be referred to as a hydrogen storage tank.

[0150] The station box (240) may include a control valve whose inlet is connected to the outlet or discharge valve of the hydrogen tank (230) and whose outlet is connected to the dispenser (200) or a nozzle (250) coupled to the dispenser (200). In addition, the station box (240) may include a means for adjusting the pressure, flow rate, temperature, etc. of the hydrogen being discharged, or a component that performs a function corresponding to such a means. For example, the station box (240) may be equipped with sensors for measuring the pressure, flow rate / speed, temperature, etc. of the hydrogen being discharged.

[0151] The nozzle (250) may be connected at one end to the hydrogen fuel supply system of the dispenser (200) via a conduit or flexible pipe of a predetermined length. The nozzle (250) may have a shape or structure that tightly and firmly engages with the receptacle of the vehicle (100) at the other end.

[0152] The nozzle (250) can be engaged with the receptacle (150) as shown in Fig. 2. At this time, the engagement status of the nozzle (250) and the receptacle (150) can be transmitted in the form of a predetermined signal or information to the first electronic control device (110) or the vehicle system (120) by the first sensor (160) installed in the vehicle and the second sensor (260) attached to the nozzle (250), and / or can be transmitted to the second electronic control device (210) or the charging station system (220).

[0153] Hydrogen fuel precooled at a hydrogen charging station (300) can be supplied to a hydrogen storage system (140) of a hydrogen electric vehicle (100) through a nozzle (250) of a dispenser (200) and a receptacle (150) of a hydrogen electric vehicle (100). At this time, the hydrogen fuel supply process can be controlled based on parameters including a pressure rise rate (PRR) and / or an average pressure rise rate (average PRR, APR).

[0154] To address the phenomenon of the temperature of hydrogen gas rising during hydrogen fuel supply (see FIG. 4), the hydrogen charging station (300) may further include a pre-cooler (280) in addition to the charging station system (220). The pre-cooler (280) lowers the temperature of the hydrogen gas through pre-cooling. The pre-cooler (280) may be installed in or coupled to at least one of the hydrogen tank (230) and the station box (240). Furthermore, the pre-cooler (280) may of course be installed in or coupled to a pipe that transports hydrogen in the hydrogen charging station (300).

[0155] The interface between the hydrogen charging station (300) and the vehicle (100) can be handled by the dispenser (200). The dispenser (200) can be configured to control the target pressure and injection speed for hydrogen fuel supply by synthesizing information indirectly obtained from the vehicle tank (130) and fuel supply information of the hydrogen charging station (300).

[0156] Additionally, the charging station system (220) and / or the dispenser (200) may be equipped with a protocol for supplying hydrogen fuel to the vehicle (100) according to a set procedure. This fueling protocol may also be equipped in the vehicle (100). The fueling protocol equipped in the vehicle (100) or the dispenser (200) may include at least a portion of a communication protocol according to an SAE standard, an ISO standard, etc., and vice versa.

[0157] For example, the method of transmitting information from a vehicle (100) to a dispenser (200) can be divided into a communication method and a non-communication method. In the case of the existing communication method, the temperature and pressure values ​​of the vehicle tank (130) of the vehicle (100) are simply transmitted in one direction to the dispenser (200), and the dispenser (200) does not actively utilize the information, but only utilizes it as a safety standard such as an emergency stop at the limit temperature and pressure. In addition, although the hydrogen fueling protocol for safe and rapid fueling is managed in the dispenser (200), it only has a minimum safety management device that automatically releases hydrogen through a pressure relief device (PRD, 170) without active safety management of the vehicle tank (130).

[0158] Accordingly, in this embodiment, the dispenser (200) actively utilizes information such as temperature and pressure of the vehicle tank (130) of the vehicle (100) through two-way communication, thereby safely and quickly managing the hydrogen fuel supply process in this environment. In particular, the dispenser (200) actively manages the vehicle tank (130) to ensure reliable safety management.

[0159] To determine minimum safety requirements, simulations using thermodynamic modeling can be performed for various situations. The resulting parameters can be used in a table-based approach or a partial real-time correction method based on the marginal cost formula (MC formula). These minimum safety requirements can include upper limits on CHSS temperature and pressure conditions, as well as guidelines for the state of charge (SOC).

[0160] If the status values ​​related to hydrogen charging are not actively controlled in the dispenser (200), the table-based method may have very low efficiency because the temperature of the pre-cooled hydrogen fuel provided from the gas filling station or the temperature of the vehicle tank (130) measured in the vehicle (100) are not utilized, and it may be difficult to flexibly respond to changes in the surrounding conditions. In addition, if the status values ​​related to hydrogen charging are not actively controlled in the dispenser (200), the MC-Formula-based method compensates for the temperature of the pre-cooled hydrogen fuel in real time, but the calculation and application methods are complicated and the application is limited, making it difficult to expand. In this way, in hydrogen fuel supply, the communication protocol should be developed with the main goal of completing safe fuel supply, and should be operated so that it can actively control unexpected situations such as excessive pre-cooling or overheating of the vehicle tank (130), and should be operated so that it can quickly take action when errors such as increased operating costs due to overcooling or delayed charging due to overheating occur.

[0161] For example, when hydrogen fuel is charged into a vehicle tank (see 130 in FIG. 1), the internal temperature of the vehicle tank rises due to the heat of compression, which in turn raises the temperature of the hydrogen fuel inside the vehicle tank. The vehicle tank is configured to cover the dome and body of the vehicle tank with carbon fiber, which has low heat transfer efficiency, in order to block heat exchange between the external atmosphere and the hydrogen fuel stored inside. Therefore, when the temperature of the hydrogen fuel inside the vehicle tank rises during the charging process, the temperature increase visible on the surface of the vehicle tank may be minimal compared to the internal temperature increase until the charging is complete due to the low heat transfer characteristics of the vehicle tank.

[0162] To explain more specifically, the temperature control of the hydrogen fuel supply process can be aimed at controlling the internal temperature of the vehicle tank to be 85℃ or lower at the time of final charging completion by receiving pre-cooled hydrogen gas. That is, as shown in the characteristic curve for hydrogen temperature during hydrogen fuel supply in FIG. 4, the temperature of the hydrogen fuel can change according to the stages in which the hydrogen temperature decreases at a constant rate in Phase I (P1), which is the pre-cooling stage of the hydrogen charging station, the temperature of the hydrogen fuel gradually increases due to the thermal mass of the hydrogen charging station in Phase II (P2), which is the stage in which hydrogen fuel is supplied from the hydrogen charging station to hydrogen mobility such as vehicles, the temperature of the hydrogen fuel further gradually increases due to the thermal mass of the vehicle in Phase III (P3), which is the stage in which hydrogen fuel is transferred from inside the vehicle to the vehicle tank, and the temperature of the hydrogen fuel rapidly increases due to the heat of compression in Phase IV (P4), which is the stage in which hydrogen fuel is compressed and stored in the vehicle tank.

[0163] Accordingly, the hydrogen fuel supply two-way communication process of the present embodiment is configured to perform the hydrogen fuel supply procedure effectively, quickly, and with high stability through active state variable control reflecting real-time measurement data, and can provide a message format of a protocol for two-way communication such as communication protocol negotiation, fuel supply protocol negotiation, fuel supply parameter negotiation, monitoring and control, and error handling.

[0164] The hydrogen fuel supply control process described above includes a process of supplying pre-cooled hydrogen gas from a hydrogen charging station (300) to hydrogen mobility (300) via a dispenser (200). The hydrogen fuel supply control can be performed by parameter control including a pressure rise rate (PRR) or an average pressure rise rate (APR) to control the fuel supply speed.

[0165] The dispenser (200), which is responsible for the interface between the hydrogen charging station (100) and the hydrogen fuel mobility (300), synthesizes hydrogen fuel supply-related information (first information) such as the ambient temperature and delivered gas temperature of the hydrogen charging station (300) and vehicle tank-related information (second information) such as the initial gas pressure of the hydrogen mobility (100) to control the target pressure, target time, limit temperature, injection speed, etc. in the hydrogen fuel supply, and a control logic following the SAE J2601 standard can be used as the control logic. The injection speed, i.e., the hydrogen fuel supply speed, can be controlled based on the average pressure increase rate.

[0166] In addition, the hydrogen fuel supply controller (210) can be designed to operate at the highest fuel supply speed that satisfies conditions below the safety limit by controlling the hydrogen fuel supply speed in real time by utilizing real-time temperature data of the vehicle tank (130). Accordingly, the hydrogen fuel supply time can be shortened within the available range. This hydrogen fuel supply controller (210) can be implemented based on an artificial neural network (ANN) with a well-known structure.

[0167] In particular, when the hydrogen gas is supplied to the vehicle (100) after being excessively precooled, such as when the temperature of the vehicle tank (130) is measured to be around 40 to 50°C at the time of completion of fuel supply by excessively setting the safety limit conditions in the hydrogen fuel supply protocol, problems such as poor precision control and / or reduced stability or reliability may occur. Accordingly, in the present embodiment, the required amount of precooling and the amount provided are actively adjusted to optimize the cooling load of the hydrogen charging station (300), thereby enhancing the stability and reliability of the hydrogen fuel supply process and increasing the operational efficiency of the hydrogen charging station (300).

[0168] In addition, existing technology protocols centered on compact or lightweight hydrogen fuel cell vehicles have the disadvantage of requiring most variables to be re-set and reapplied when supplying hydrogen fuel to new mobility. Therefore, in this embodiment, by applying ANN-based hydrogen fuel cell control logic that automatically updates its own logic through a certain learning and training process, the hydrogen fuel cell can be configured to effectively perform and control the hydrogen fuel cell supply process even for unfamiliar hydrogen fuel cell vehicles, i.e., new hydrogen cells that are connected to the dispenser (200) for the first time.

[0169] Furthermore, the hydrogen fueling process can be simulated using thermodynamic modeling for various situations, meeting minimum safety requirements, and partial real-time compensation can be performed based on the MC formula protocol. Of course, depending on the implementation, a table-based protocol can be applied, utilizing parameters derived from the simulation to construct a lookup table and controlling the fueling output using the configured lookup table.

[0170] The minimum safety requirements described above may follow the upper limits of the temperature and pressure conditions of the CHSS of the hydrogen storage system (140) and the guidelines for the state of charge (SOC). Furthermore, the simulation may be performed through thermodynamic modeling using boundary conditions including best and worst cases.

[0171] The above-described configuration can also be applied to the configuration of an embodiment of the present invention within the scope consistent with the purpose of the present invention.

[0172] FIG. 5 is an exemplary diagram showing a framework (hereinafter also referred to as a “fuel supply framework”) for functional blocks of a hydrogen fuel supply procedure to which a hydrogen fuel supply two-way communication method according to an embodiment of the present invention can be applied.

[0173] Referring to FIG. 5, the fueling framework may include use case (UC)-specific functional blocks for discovery and pairing, communication security, communication protocol negotiation, fueling protocol negotiation, fueling parameter negotiation, safety check-in, monitoring and control, safety check-out, termination, error handling, and emergency handling.

[0174] That is, the fuel supply framework may include, as use case-specific function blocks, a discovery and pairing function block, a communication security function block, a communication protocol negotiation function block, a fuel supply protocol negotiation function block, a fuel supply parameter negotiation function block, a safety check-in function block, a monitoring and control function block, a safety check-out function block, a termination function block, an error handling function block, and an emergency handling function block.

[0175] Each functional block of the fuel supply framework corresponds to a respective use case (UC1 to UC11) in the order described, and can function as a subject that performs the time-series steps (S501 to S511) of these use cases (UC1 to UC11). Here, the tenth use case (UC10) and the eleventh use case (UC11) can be independently connected to the third use case (UC3) to the eighth use case (UC8) by the respective functional blocks to perform error processing and / or emergency processing occurring in the corresponding use cases.

[0176] The aforementioned use cases (UC1 to UC11) for hydrogen fueling can be configured to collectively process the overall hydrogen fueling procedure in a consistent manner to ensure safe and secure fueling communication. That is, a vehicle or dispenser can execute most of the use cases (UC3 to UC11) in various orders depending on the circumstances between the vehicle and the dispenser to achieve the goal of stable and secure hydrogen fueling.

[0177] Additionally, after the dispenser nozzle and the vehicle receptacle are connected to each other, the vehicle and the dispenser can communicate to supply fuel to implement each use case. However, the vehicle and the dispenser may omit certain use cases as needed based on predefined requirements.

[0178] Each of the use cases described above can be implemented through communication between the control system of the dispenser that supplies fuel to the hydrogen mobility according to the fuel supply protocol for hydrogen mobility and the hydrogen mobility.

[0179] Meanwhile, the hydrogen mobility (hereinafter also referred to simply as "mobility" or "vehicle") and dispenser implementing the aforementioned use case can exchange data for vehicle identification in the first use case (UC1). To this end, the vehicle may be equipped with sensors, an electric control unit (ECU), a transmitter, and a receiver. For two-way communication, the transmitter and receiver may be provided as an integrated unit or separately. An integrated transmitter and receiver may be referred to as a transceiver.

[0180] Additionally, the dispenser may be configured to receive specific data from the vehicle. The dispenser may store data for data logging or store data designated by the charging station's programmable logic controller (PLC) for use in the fueling protocol. Data logging may refer to a process of collecting and recording data over a period of time to analyze a specific operating state of a hydrogen fueling system or to record data-based events or operations in a system or network environment, or to data collected and recorded by this process.

[0181] For two-way communication, the charging station is equipped with sensors specified by the fuel supply protocol. The charging station's PLC or electronic control unit can obtain measurements from the sensors and transmit these measurements to the vehicle. The aforementioned vehicles and charging stations can use standard communication protocols such as infrared, Wi-Fi, or Bluetooth.

[0182] Additionally, the vehicle and dispenser can establish a physically connected communication channel at the vehicle-dispenser interface. The pairing process for establishing this communication channel can be performed using wired, optical, or wireless technologies.

[0183] The discovery and pairing procedure of the first use case (UC1) may have preconditions such that the nozzle of the dispenser is inserted into and firmly connected to a vehicle receptacle, i.e., a vehicle fueling receptacle. The vehicle fueling receptacle may be simply referred to as a vehicle receptacle or receptacle. The discovery and pairing procedure may be referred to as a dispenser discovery protocol (DDP), or simply as a pairing process.

[0184] A DDP can be initiated by a DDP request message (DDPRequest) broadcast by a mobility. The DDP request message can include a pairing ID (pairing_id) of the mobility. The dispenser can receive the DDP request message and, in response to the DDP request message, send a DDP response message to the mobility. The DDP response message can include the IP address of the dispenser (IPAddr), the TCP port number of the dispenser (TCPPort), the UDP port number of the dispenser (UDPPort), and the pairing ID of the dispenser (pairing_id).

[0185] Furthermore, the vehicle and dispenser inherently know which communication protocol to follow. Therefore, subsequent communications after UC1 can rely on the communication protocol agreed upon in the current use case (UC1) as a post-condition of the discovery and pairing process. If either the vehicle or dispenser selects a communication protocol outside the agreed upon scope, the selected communication may not occur. In other words, even if the pairing process completes successfully, authorization for fuel delivery or the fuel delivery protocol may not yet be granted.

[0186] Any method used to pair the vehicle and dispenser must be designed to avoid increasing the risk of ignition or explosion beyond an acceptable level. For example, any wired pairing method can be designed to mitigate or prevent sparking hazards caused by electrostatic discharge.

[0187] In terms of the effectiveness of physical pairing, any method used to pair a vehicle and a dispenser may be integrated into a vehicle-dispenser interface or installed to provide proximity between the vehicle's fuel supply receptacle and the dispenser's nozzle and hose assembly. Here, the interface may refer to something physically integrated into the nozzle and receptacle interface. Proximity may be defined by hardware associated with the pairing method.

[0188] For example, the physical geometry used for infrared communication, including the allowed distance between the transmitter and receiver, may be specified. Furthermore, the physical configuration of the hydrogen fueling hardware may be pre-specified, wherein proximity may not include a pairing method that risks pairing a physically unconnected vehicle with the dispenser, such as a relatively long-range wireless communication technology such as Bluetooth. Infrared communication may be referred to as infrared data association (IrDA) communication and may include bidirectional infrared (bi-IrDA) communication.

[0189] Referring again to FIG. 5, the hydrogen fuel supply two-way communication method according to the present embodiment is a communication method for hydrogen fueling performed by a communication device or a communication control device of hydrogen mobility, that is, a two-way communication method performed by hydrogen mobility and a dispenser, and may include a step (S503) of negotiating a communication protocol with a dispenser that supplies hydrogen to hydrogen mobility, a step (S504) of negotiating a fuel supply protocol for hydrogen fueling with the dispenser, and a step (S505) of negotiating fuel supply parameters with the dispenser based on the negotiated fuel supply protocol.

[0190] In addition, the hydrogen fuel supply two-way communication method according to the present embodiment is a communication method for hydrogen fuel supply by a dispenser that supplies hydrogen to hydrogen mobility, that is, a two-way communication method performed by the dispenser and the hydrogen mobility, and may include a step of negotiating a communication protocol with the hydrogen mobility (S503), a step of negotiating a fuel supply protocol for hydrogen fuel supply with the hydrogen mobility (S504), and a step of negotiating fuel supply parameters with the hydrogen mobility based on the negotiated fuel supply protocol (S505).

[0191] Each use case will be further specified by a detailed description referring to Figures 8 to 32 below.

[0192] FIG. 6 is an exemplary diagram showing a communication stack related to each use case of FIG. 5 to which a hydrogen fuel supply two-way communication method according to an embodiment of the present invention can be applied, based on the OSI (open systems interconnection) 7 layer, which is a reference model.

[0193] As shown in Fig. 6, the communication stack related to each use case of the communication method for hydrogen fueling can be expressed as protocol suites for the data link and physical layer, the network layer, the transport layer, the security layer, the session layer, the presentation layer, and the application layer belonging to the OSI 7 layers. The communication stack for hydrogen fueling can be implemented by one or a combination of hardware modules and software modules in a computing device having a means or component for performing a communication device, a communication control device, or a similar function.

[0194] More specifically, in relation to the data link and physical layers, the communication stack may include at least one first protocol (610) selected from bidirectional IrDA (bi-IrDA), WLAN, NFC, etc., or at least one first component performing the function of such first protocol (610).

[0195] Additionally, with respect to the network layer, the communication stack may include an Internet Protocol Version 6 (IPv6) protocol (620). The IPv6 protocol may be referred to as a second protocol.

[0196] Additionally, in relation to the transport layer, the communication stack may include at least one third protocol (630) selected from transmission control protocol (TCP), user datagram protocol (UDP), etc.

[0197] Additionally, in relation to the security layer, the communication stack may include at least one fourth protocol (640) selected from transport layer security (TLS), datagram transmission layer security (DTLS), etc. TLS may include versions such as TLS 1.2 and TLS 1.3, and DTLS may include versions such as DTLS 1.2 and DTLS 1.3. TLS may be implemented in a TCP socket, and DTLS may be implemented in a UDP socket.

[0198] Additionally, with respect to the session layer, the communication stack may include a JSON (JavaScript object notation)-based session protocol (650). The JSON-based session protocol (650) may be used when communicating between a vehicle and a dispenser or when transmitting and receiving data between an electronic control unit of a vehicle and an electronic control unit of a charging station.

[0199] Additionally, with respect to the presentation layer, the communication stack may include JSON (660). JSON is one of the formats that can be used when sending data from a server to a client. Using JSON, protocol messages between a vehicle and a dispenser, or between a vehicle's electronic control unit and the electronic control unit of a charging station / dispenser, can be expressed in JSON.

[0200] In addition, with respect to the application layer, the communication stack may include fueling protocols (FP) (670) for hydrogen fueling. The fueling protocols (670) include a first fueling protocol (FP1), a second fueling protocol (FP2), and an nth fueling protocol (FP n ) can be included. n can be any natural number greater than or equal to 3.

[0201] In another embodiment, the communication stack for hydrogen fueling may be configured to utilize PLC (programmable logic controller), WLAN, etc. as protocols of the data link and physical layers and network layer, TCP and / or IPv6 as protocols of the transport layer and security layer, binary XML (binary extensible markup language) protocol as protocol of the session layer corresponding to the encoding layer, and one of the existing protocols used in electric vehicles as protocols of the presentation layer and application layer.

[0202] Existing protocols used in electric vehicles may include protocols for performing procedures such as direct current (DC) charging, alternating current (AC) charging, wireless power transfer (WPT), and automatic connection device pantograph (ACDP).

[0203] The overall communication data items exchanged between the vehicle and the charging station through the communication stack for hydrogen fuel supply described above are as shown in Table 1 below.

[0204] Charging station → Vehicle → Charging station communication data items - Supply hydrogen pressure - Supply hydrogen temperature - Supply hydrogen flow rate - Maximum supply hydrogen pressure - Maximum supply hydrogen temperature - Minimum supply hydrogen temperature - Maximum supply hydrogen flow rate - Ambient temperature - Communication charging status - Target value - Charging progress status - Emergency stop status - Hydrogen charging protocol category - Supply hydrogen amount - Expected completion time of hydrogen charging - Receptacle type - Receptacle operating pressure - Tank volume - Tank pressure - Tank temperature - Maximum operating pressure - Maximum operating temperature

[0205] FIG. 7 is an example diagram illustrating a JSON (Javascript object notation) message format that can be used in the presentation layer or session layer of the communication stack for hydrogen fuel supply of FIG. 6. The JSON message format represents a message format of a text-based data exchange standard that is human-readable and easy to exchange and store. The JSON message format is easy to understand, supports schema validation and flexibility when necessary, and can be used for most web traffic. Accordingly, the communication method of the present embodiment can be configured to utilize the JSON format.

[0206] For example, a communication device for hydrogen fuel supply may use a JSON message format (700) as illustrated in FIG. 7 in a protocol of the presentation layer or session layer.

[0207] In the JSON message format (700), the JSON data of each field is composed of a pair of names and values ​​entered with double quotation marks (""), i.e., in the format of "key": "value", and the JSON object of the header part or message (message, msg) part is expressed in a form surrounded by a single curly bracket ({}), and can be composed to include multiple properties by using a comma (,) within the curly brackets.

[0208] This JSON message (700) can be used for a communication protocol negotiation request (CommProtNegoReq) message, etc. The communication protocol negotiation request message includes a header part and a message (msg) part.

[0209] In the JSON format message employed in this embodiment, the header portion includes fields or properties with names such as a timestamp (ts), a session identifier (session ID, sid), and a message identifier (message ID, mid), respectively. The timestamp is paired with a value indicating when the message was sent in coordinated universal time (UTC) or generalized time format. The session identifier is paired with a value indicating a unique session identifier assigned by the dispenser. In addition, the message identifier is paired with a value indicating a message identifier for a specific message, such as a communication protocol negotiation message (CommProtNegoReq).

[0210] Additionally, the message (msg) part may contain a JSON object, which is an application message in JSON format. The JSON object may contain a field with the data name of the protocol (protocols). The protocol field may contain multiple protocols, each of which contains the properties of index (idx), name (name), version (version, ver), and preference (pref) in the form of an array within square brackets ([]).

[0211] Hereinafter, the operating principles of each use case for hydrogen fuel supply processed by each protocol of the communication stack of FIG. 5 will be described in more detail with reference to FIGS. 8 to 32.

[0212] First, the first use case (UC1) of the discovery and pairing step (see S501 in FIG. 5) is configured to identify a communication counterpart (a communication module of the vehicle or dispenser) responsible for controlling the receptacle and nozzle to which the vehicle or dispenser / charging station is physically connected. UC1 may also define a method for identifying incompatibility with the communication counterpart and define a safety mechanism.

[0213] In this first use case (UC1), the vehicle and dispenser may attempt to discover a common communication technology to implement the hydrogen fueling protocol. The vehicle and dispenser can discover each other and initiate communication based on discovery mechanisms provided by the data link and physical layers. To establish a communication channel with the device connected to the hose assembly for hydrogen fueling, an additional pairing procedure is required. For example, in the case of wireless communication, a separate pairing channel may be required to convey pairing information. If pairing is implicitly guaranteed, the pairing procedure can be fulfilled solely through the communication channel of the communication controller integrated with the hose assembly, for example.

[0214] Table 2 illustrates the objectives, short description, pre-conditions, and post-conditions of the use case (UC1) in the discovery and pairing phase.

[0215] Type Description Use Case Name UC1: "Discovery and Pairing" Purpose UC1 allows a device to identify its communication partner (the communication module of the vehicle or dispenser) responsible for controlling the physically connected outlet or nozzle, respectively. UC can also define methods for identifying incompatibilities and define fail-safe mechanisms. Brief Description In this use case, the vehicle and the dispenser attempt to find a common communication technology to implement the fueling protocol. Based on the discovery mechanism provided by the underlying physical / data link layer, the vehicle and dispenser discover each other and initiate communication. Additional pairing procedures may be required to ensure that a communication channel is established with the device connected to the fueling hose assembly. If the communication channel does not guarantee correct pairing (e.g., wireless communication), an additional pairing channel may be required to convey the pairing information. If pairing is implicitly guaranteed (e.g., integrated communication with the hose assembly), the communication channel alone should suffice. Prerequisite: The dispenser nozzle is firmly connected to the vehicle outlet. Postrequisite: The vehicle and the dispenser know which communication medium to use for communication. Subsequent communication after this use case relies solely on the communication protocol agreed upon in this use case. If a protocol outside the scope of this use case is selected, further communication will not occur.

[0216] Table 3 illustrates the supported communication technologies, communication channels, and pairing channels that can be used in the first use case (UC1) of the discovery and pairing phase.

[0217] CategoryCommunication TechnologyCommunication ChannelPairing ChannelA P.2Bidirectional IrDA(irDA references)N / AA P.3WLAN with NFCIEEE 802.11NFC ForumSpecifications

[0218] In the discovery and pairing step described above, a mobility such as a vehicle can broadcast a message containing its pairing ID (PAIR_ID), i.e., vehicle ID (vehicle_id). A dispenser can send a reply message to the vehicle indicating that it has received the vehicle ID from the vehicle. The vehicle can send a message to the dispenser indicating that it has successfully received an acknowledgment (ACK) message indicating that it has received the vehicle ID. Next, the dispenser can broadcast a message containing its pairing ID, i.e., dispenser ID (dispenser_id). The vehicle can send a reply message to the dispenser indicating that it has received the dispenser ID. The dispenser can send a message to the vehicle indicating that it has successfully received the ACK message indicating that it has received the dispenser ID.

[0219] This send-echo-verification method allows vehicles and dispensers to use session-specific, randomized pairing IDs. This send-echo verification method addresses privacy concerns surrounding pairing ID exchange. That is, trust in the pairing process influences subsequent processes, and for this purpose, the session-specific pairing ID can be included in the data used to establish trust.

[0220] Additionally, communication devices for hydrogen fueling may be configured as devices with backward compatibility or devices with interoperability. When categorizing devices based on interoperability, communication devices for hydrogen fueling can be categorized into Type 0, Type 1, Type 2, and Type 3.

[0221] A Type 0 device may refer to a device that does not support fueling communication or does not receive such communication messages. A Type 1 device may refer to a device that supports IrDA communication for fueling. A Type 1 device may fallback to a Type 0 device. A Type 2 device may refer to a device that supports advanced communication (AC). A Type 2 device may fallback to a Type 0 device. And a Type 3 device may refer to a device that supports IrDA and advanced communication. A Type 3 device may fallback to any one of Type 0, Type 1, and Type 2 devices.

[0222] Here, IrDA (infrared data association) communication can refer to a communication method based on a physical communication protocol used for relatively short-range data exchange, such as a PAN (personal area network), as a wireless communication using infrared rays promoted by the International Infrared Data Communication Association.

[0223] Advanced communications can refer to a communication method that uses a medium such as WLAN (wireless local area network), Bluetooth (BT), NFC (near field communication), WiFi, UWB (ultra-wideband), RFID (radio frequency identification), 4th generation (4G), 5th generation (5G), and a specific protocol. Specific protocols can include TCT / IP (transmission control protocol / internet protocol), fueling protocol, etc.

[0224] Advanced communications can also include bidirectional IrDA, serial communications, automotive Ethernet (ETH), and high-level communications. High-level communications can handle any amount of information exceeding that handled by command and control communications. The data link for high-level communications can use, but is not limited to, power line communications (PLC).

[0225] Additionally, advanced communications may take the form of hybrid forms, combining IrDA and wired or IrDA and wireless. The IrDA and wired form may include a nozzle and receptacle that combine IrDA communication means and wired channel means.

[0226] In this way, advanced communications can support both wired and wireless bidirectional communication technologies. For wireless communication, the system may include a communication means supporting at least one of 5G, WLAN, BLE, ETH, UWB, RFID, NFC, etc. Known protocols such as TCP / IP can be used as protocols for these communication means. Furthermore, advanced communications can also support wireless communication technologies such as inductive, Wi-Fi for ACD (autoconnect charging device), and UWB for ACD.

[0227] In practice, a communication device for hydrogen fueling can be implemented to support different communication technologies from the other communication device. Accordingly, the communication device for hydrogen fueling of the present embodiment can be configured to maximize interoperability between devices.

[0228] That is, the discovery and pairing phases can be performed based on interoperability or compatibility information shared between the mobility and the dispenser. Specifically, the communication protocol negotiation, fuel supply protocol negotiation, and fuel supply parameter negotiation and their determination processes, described below, can be performed within the scope of interoperability or compatibility. Interoperability or compatibility information is identified and shared during the discovery and pairing phases, but can be re-identified and updated in subsequent phases to reflect the current situation.

[0229] For example, when a Type 1 device supporting Specification #1 according to a given standard encounters a Type 0 device or a Type 2 device, the Type 1 device can fall back to the Type 0 device. Furthermore, when a Type 2 device supporting Specification #2 according to a given standard encounters a Type 0 device or a Type 1 device, the Type 2 device can fall back to the Type 0 device. Furthermore, when a Type 3 device supporting Specification #2 encounters a Type 0 device, the Type 3 device can fall back to the Type 0 device. Furthermore, when a Type 3 device encounters a Type 1 device, the Type 3 device can fall back to the Type 1 device. Furthermore, when a Type 3 device encounters a Type 2 device, the Type 3 device can fall back to the Type 2 device. The aforementioned Specification #1 may include the SAE (Society of Automotive Engineers) standard, etc. The Specification #2 may include the ISO 19885-3 standard, etc.

[0230] Additionally, to support interoperability, communication devices for hydrogen fueling can perform connection compatibility checks. For example, a hydrogen mobility or charging station can perform connection compatibility checks as in any of Scenarios 1 to 3 below, depending on whether it supports WLAN, one of the advanced communication technologies.

[0231] In Scenario 1, the dispenser may be equipped with or utilize an access point (AP), a wireless router. The dispenser may support fuel station beaconing and vehicle supply equipment (VSE) refueling. Vehicles approaching the dispenser can scan for the dispenser and establish a WLAN link with it.

[0232] In Scenario 2, the dispenser may support IrDA communication but not WLAN communication. For example, if the dispenser is a Type 1 device, a vehicle (Type 3 device) in proximity to the dispenser will not be able to detect the dispenser (Type 1 device) through scanning. However, when the vehicle's receptacle is connected to the nozzle attached to the dispenser's cable, IrDA communication between the vehicle and the dispenser can be initiated.

[0233] In Scenario 3, the dispenser can support both WLAN and IrDA communications. In this case, the dispenser becomes a Type 3 device. A vehicle, a Type 1 device, can be parked near the dispenser. The dispenser cannot yet find any WLAN clients. However, when the vehicle's receptacle is connected to the nozzle attached to the dispenser's cable, IrDA communication between the vehicle and the dispenser can begin.

[0234] In addition, in the discovery and pairing step described above, the communication controller of the hydrogen mobility or the communication controller of the charging station can exchange pairing IDs and confirm the pairing ID of the other party when pairing at UCDC Level 2 (UCDC-2) and UCDC Level 3 (UCDC-3). That is, the vehicle and the dispenser can have a pairing identity (identity / identification, ID), and the requirements for exchanging such identities can be classified by the use classification of data communicated (UCDC) level. The UCDC level can have UCDC Level 1 (UCDC-1), UCDC Level 2 (UCDC-2), and UCDC Level 3 (UCDC-3). The UCDC level can further have UCDC Level 0 (UCDC-0).

[0235] The aforementioned UCDC is a concept that should be considered when designing or developing standards related to hydrogen refueling, and requires criteria such as communication, active control, and safety features. Specifically, UCDC can represent a numerical ranking of data transmitted between a vehicle and a dispensing system based on the use of a fueling protocol supported by a risk assessment, and can be defined into four levels, from Level 0 to Level 3.

[0236] UCDC Level 0 indicates when no data is transmitted, such as no communication or non-communication. UCDC Level 0 (900) may refer to communication that is not used by the fueling protocol for dispensing hydrogen or related safety functions, or when data is transmitted. UCDC Level 0 does not support communication between the vehicle and the dispenser, so the dispenser cannot transmit the pairing ID to the vehicle during process control or safety functions.

[0237] UCDC Level 1 indicates that data transmitted at UCDC Level 1 is not used for safety functions, but can be used for data collection and, if measures are taken to mitigate the risk (or risks) of a fault, to enhance the performance of basic process control for the fuel delivery protocol. UCDC Level 1 does not support bidirectional communication, so communication channel security may not be possible.

[0238] When pairing at UCDC Level 1, the vehicle can transmit its pairing ID to the dispenser. While the data transmitted at UCDC Level 1 is not used for safety functions, the static data transmitted can be used to improve the performance of the fueling protocol, and the dynamic data transmitted can be used to reduce the risk of process deviations within the fueling protocol.

[0239] UCDC Level 2 indicates that static data delivered at UCDC Level 2 may be used for safety functions in addition to the permitted uses for static and dynamic data defined at UCDC Level 1. Static data at UCDC Level 2 may be in addition to the permitted uses for static and dynamic data defined for UCDC Level 1.

[0240] UCDC Level 3 indicates that static and dynamic data can be used for dynamic control within a protocol or safety function. UCDC Level 3 dynamic data may be in addition to the permitted uses for static and dynamic data defined for UCDC Level 2.

[0241] Pairing a vehicle and dispenser at UCDC Level 2 and UCDC Level 3 indicates that the vehicle and dispenser can be configured to provide sufficient information to secure the communication to a specific security level, such as IEC 62443 Security Level 3. IEC 62443 Security Level 3 may be a security level for actors with adequate resources and appropriate motivation.

[0242] As described above, the UCDC levels can have a form where UCDC level 1 is included in UCDC level 2, and UCDC level 2 is included in UCDC level 3, i.e., a higher level includes a lower level. A device supporting a specific UCDC level can support a device with a lower UCDC level. Devices supporting different UCDC levels can use the highest UCDC level supported by both devices. It can be said that the UCDC levels described above also easily support UCDC level 0. It can be seen that the UCDC levels are backward compatible. In a variation of the present embodiment, backward compatibility can be effectively applied to each of Non-Comm, Uni-directional Comm., Bi-directional Comm., and combinations thereof, regardless of the UCDC level.

[0243] Meanwhile, if secure communication is supported at a specific UCDC level, at least one of the vehicle and the dispenser can verify that the pairing provides sufficient information to secure the communication channel for any method used to pair the vehicle and dispenser. For example, the pairing may include the exchange of encryption keys to enable the vehicle and dispenser to perform secure communication (see S502 in FIG. 5 ) during fueling.

[0244] Next, the authentication process of the communication security procedure that can be employed in the communication device for hydrogen fuel supply according to the present embodiment will be described in more detail as follows.

[0245] Hydrogen mobility can transmit a request message to the dispenser requesting a list of authorization methods. The dispenser can then transmit a response message to the hydrogen mobility (hereinafter referred to simply as "mobility") requesting a list of authorization methods. The response message may include information on a list of authentication methods related to external authentication procedures, such as radio frequency identification (RFID), credit cards, or debit cards, or to its own authentication procedures.

[0246] Next, the mobility can transmit an authentication request message to the dispenser, including a specific method selected from a list of authentication methods, such as RFID. The dispenser can then transmit a response message to the mobility's authentication request. This response message may include information indicating that the selected authentication method is working.

[0247] Next, the mobility can perform authentication using the previously selected authentication method based on the dispenser's response and send a confirmation request message to the dispenser regarding the authentication. Once authentication is complete, the dispenser can send a "Done (success)" message to the mobility. However, if the authentication completion is not confirmed or not performed, the aforementioned series of steps may be repeated.

[0248] According to the above configuration, the dispenser can check whether the mobility is authorized, i.e., whether the user of the mobility is authorized to supply hydrogen fuel, before proceeding further with the hydrogen fueling process.

[0249] To secure the authentication process, a hydrogen fueling device including at least one of a mobility device and a dispenser may establish a TCP connection via a transport layer protocol after a data link and physical layer connection is established between the mobility device and the dispenser, then perform a TLS handshake to process authentication and exchange keys to establish a secure communication channel. Additionally, UDP communication protected by DTLS may be used while exchanging security-critical information.

[0250] Additionally, the mobility and dispenser can successfully complete the discovery and pairing procedures and establish data link and physical layer connections. They can then prepare the credentials required for authentication and key exchange. This allows the communication channel between the mobility and dispenser to be encrypted and integrity-protected. At this point, the dispenser can authenticate the mobility, or optionally, the mobility can authenticate the dispenser.

[0251] Meanwhile, in the aforementioned TLS handshake, mobility authentication may be required and dispenser authentication may be optional, in which case the dispenser may be configured to act as a client and the mobility as a server.

[0252] For TLS handshakes, the mobility and dispenser must prepare the necessary credentials. They can store the certificate chain, the corresponding private key, and the trust anchor certificate in a secure repository that protects them from unauthorized access.

[0253] During the TLS handshake, the mobility can request client authentication from the dispenser by sending a predefined CertificateRequest message. Upon receiving the CertificateRequest message, the dispenser can then send the certificate and CertificateVerify messages to the mobility to transmit the certificate.

[0254] Mobility can abort the TLS handshake by sending an alert message with the "certificate_required" alert code if the dispenser does not send a certificate verification message along with the certificate when sending a certificate request message to the dispenser along with a handshake message such as ServerHello.

[0255] According to the above-described embodiment, the objectives, short description, pre-conditions and post-conditions of the second use case (UC2) of the Communication Security phase can be defined as shown in Table 4 below.

[0256] Type Description Use Case Name UC2: "Communication Security" Purpose The vehicle and dispenser establish a secure channel for the discovered communication channel to achieve communication security goals including confidentiality, integrity, and privacy. Short Description After the physical and data link layer connections are established between the vehicle and the dispenser, they establish Layer 3, establish a TCP connection, and then perform a TLS handshake to authenticate and exchange keys to establish a secure communication channel. Prerequisites The vehicle and dispenser successfully perform the discovery and pairing use cases and establish a data link layer connection. Credentials required for authentication and key exchange are available. Postrequisites The dispenser authenticates the vehicle, and the vehicle authentication dispenser is successfully authenticated. The communication channel between the vehicle and the dispenser is encrypted to protect its integrity.

[0257] FIG. 8 is an exemplary diagram illustrating a communication protocol negotiation procedure among the framework of functional blocks of the hydrogen fueling procedure of FIG. 5 (hereinafter simply referred to as the “fueling framework”) and a communication protocol negotiation request message applicable to the functional block. FIG. 9 is an exemplary diagram illustrating a JSON message format of the communication protocol negotiation request message of FIG. 8. FIG. 10 is an exemplary diagram illustrating a communication protocol negotiation procedure of the fueling framework of FIG. 5 and a communication protocol negotiation response message applicable to the functional block. And FIG. 11 is an exemplary diagram illustrating a JSON message format of the communication protocol negotiation request message of FIG. 10. In the communication protocol negotiation procedure, which is one of the hydrogen fueling procedures according to the present embodiment, mobility such as a hydrogen vehicle and a dispenser of a charging station can negotiate and determine a communication protocol to be used for two-way communication throughout the fueling process.

[0258] To this end, the mobility may include a step of transmitting a message to the dispenser, the message including information about a first communication protocol available to the mobility, and a step of receiving from the dispenser a message including information about a second communication protocol selected from among common communication protocols commonly available between the mobility and the dispenser based on the information about the first communication protocol.

[0259] In addition, the hydrogen fuel supply two-way communication method may be configured such that the dispenser receives a message from the mobility including information on a first communication protocol applicable to the mobility, selects a second communication protocol from among communication protocols commonly applicable to the mobility and the dispenser based on the information on the first communication protocol, and transmits a message including information on the selected second communication protocol to the mobility. Here, the hydrogen fuel supply two-way communication method may be configured such that the dispenser further requests the mobility in advance for information including a list of first communication protocols applicable to the mobility.

[0260] Meanwhile, in a two-way communication method for hydrogen fuel supply, the dispenser may be configured to first transmit a message including information on a communication protocol applicable to hydrogen fuel supply to the mobility, and when the mobility selects a specific second communication protocol from among communication protocols that can be commonly used with the dispenser, receive a message including information on the selected second communication protocol from the mobility. In this case, the two-way communication method for hydrogen fuel supply may be configured to further include a step in which the mobility requests the dispenser in advance information including a list of communication protocols applicable to the dispenser.

[0261] According to this embodiment, the objectives, short description, pre-conditions and post-conditions of the third use case ('UC-3' or 'UC3') of the Communication Protocol Negotiation procedure can be defined as shown in Table 5 below.

[0262] Description: Use Case Name: UC3: "Negotiate Communication Protocol" Purpose: The vehicle and dispenser decide which communication protocol to use throughout the fueling session. Brief Description: After the TLS handshake is successfully completed, the vehicle and dispenser negotiate which communication protocol to use throughout the charging session. Negotiation begins when the vehicle sends a list of supported protocols, the dispenser selects a common protocol supported by both, and the vehicle selects its preferred protocol. Prerequisites: A secure, authenticated communication channel is established using TLS 1.3. Postrequisites: The vehicle and dispenser agree on the communication protocol to use throughout the fueling session.

[0263] According to this embodiment, the content of the message transmitted or received between the mobility and the dispenser in the communication protocol negotiation phase can be defined as shown in Table 6 below.

[0264] Element Name Type Semantics protocols CommProtocolType Vehicle support communication protocol CommProtocolType Index Unsigned integer Index of the common protocol Name String Name of the common protocol Ver String Version of the common protocol pref Unsigned integer Preference for the protocol. Lower numbers indicate higher preference

[0265] That is, as shown in FIG. 8, information about a vehicle-supported communication protocol corresponding to the first communication protocol may include information about a common protocol type (CommProtocolType). The common protocol type may include an index of the common protocol, a name of the common protocol, a version of the common protocol (version, ver), and a preference for the common protocol (preference, pref). An example of the above-described communication protocol negotiation request message in JSON format is as shown in FIG. 9. As shown in FIG. 9, information about the first communication protocol (protocols) transmitted through the communication protocol negotiation request message (900) may include information about the first protocol and the second protocol. The first protocol may have an index of 1, a name of ISO 19885, a version of 2024, and a preference of 1 as one common protocol type (CommProtocolType). And, the second protocol may have an index of 2, a name of ISO 19885, a version of 2026, and a preference of 2, as another common protocol type. Of course, the first communication protocol may include three or more multiple protocols.

[0266] According to this embodiment, the content of a communication protocol negotiation response (CommProtNegoRes) message transmitted or received between the mobility and the dispenser during the communication protocol negotiation phase can be defined as exemplified in Table 7 below.

[0267] Element Name Type Meaning / Content Index Unsigned integer Optional: Index of the selected protocol Result resultType The result of the protocol negotiation. If the negotiation succeeds, it is 'OK'. If the negotiation fails, it is 'FAILED_INCOMPAT'.

[0268] That is, as illustrated in FIG. 10, a communication protocol negotiation response (CommProtNegoRes) message including a result of communication protocol negotiation may include an optional field, index, and information about the result of protocol negotiation. In addition, as illustrated in FIG. 11 as a communication protocol negotiation response message (1100) in JSON format, the index of the communication protocol negotiation response message may be set to a predetermined value, for example, '1'. In addition, the result field of the communication protocol negotiation response message may have an 'OK' value if the negotiation is successful, and a 'FAILED_INCOMPAT' value if not.

[0269] The aforementioned communication protocol negotiation procedure can be configured to identify a communication protocol to be followed during a hydrogen fueling session after the mobility and dispenser discover and pair with each other through the first use case 1 (UC1) process on a compatible communication channel, and perform a communication security procedure (see S502 of FIG. 5) through the second use case 2 process if necessary.

[0270] In this embodiment, the communication protocol negotiation procedure for two-way communication between the dispenser and the mobility can be configured to be performed after the communication controller of the mobility discovers and pairs with the communication controller of the dispenser using the first communication protocol, or after the communication security process, and vice versa.

[0271] Meanwhile, if the outcome of the communication protocol negotiation step relates to a specific communication protocol, the fuel supply protocol negotiation step and the fuel supply parameter negotiation step described below may be performed using that specific communication protocol. Furthermore, the communication protocol negotiation step may be performed based on information already shared regarding interoperability and / or compatibility between the mobility and dispenser during the previous discovery and pairing process.

[0272] Information on interoperability or compatibility between mobility and dispensers is basically shared during the discovery and pairing process, but may be updated during the communication protocol negotiation process due to changes in the communication environment or environmental variables related to hydrogen fueling during the hydrogen fueling procedure.

[0273] The communication protocol negotiation process can be implemented by all available communication protocols to ensure successful negotiation between different fueling protocols for each communication technology. For example, a fueling protocol utilizing a communication technology such as WLAN can use a protocol commonly supported by both the mobility device and the dispenser (hereinafter referred to as a "common protocol") to determine the communication protocol to be used in the two-way hydrogen refueling communication process.

[0274] Meanwhile, the mobility or dispenser may be configured to further perform a process of falling back to a lower type or lower UCDC level of the other party depending on the mutual type or UCDC level identified in the communication protocol negotiation procedure.

[0275] The dispenser will accept a specific protocol selected from the protocol list (<selected protocol> ) field can be transmitted to the mobility. The specific protocol field can contain information about the protocol supported by both the dispenser and the mobility and having the highest priority preferred by the mobility, as a common protocol selected by the dispenser. According to the common protocol, the mobility and the dispenser can reach an agreement on the communication protocol to be used for fueling communication.

[0276] As mentioned above, mobility can prioritize the communication protocols it supports. Mobility can then provide these prioritized communication protocols to the dispenser. Examples of prioritized communication protocols are shown in Table 8 below.

[0277] Protocol Identifier (Protocol ID)PrioritySAE J2601 - No comm.7SAE J2799 - IrDA6SAE J2601 - IrDA5ISO 19885-3-2023-UCDC-04ISO 19885-3-2023-UCDC-13ISO 19885-3-2023-UCDC-22ISO 19885-3-2023-UCDC-31

[0278] FIG. 12 is an exemplary diagram illustrating a fueling protocol negotiation procedure of the fueling framework of FIG. 5 and a fueling protocol negotiation request message applicable to its functional blocks. FIG. 13 is an exemplary diagram illustrating a JSON message format of the fueling protocol negotiation request message of FIG. 12. FIG. 14 is an exemplary diagram illustrating a fueling protocol negotiation procedure of the fueling framework of FIG. 5 and a fueling protocol negotiation response message applicable to its functional blocks. And FIG. 15 is an example diagram showing the JSON message format of the fuel supply protocol negotiation response message of FIG. 14. Referring to FIGS. 12 to 15, the fuel supply protocol negotiation procedure of the present embodiment may include a step of transmitting a fuel supply protocol negotiation request (FuelProtNegoReq) message, which includes information on a first fuel supply protocol (fueling protocols, fuelProts) applicable to the mobility based on a result of communication protocol negotiation, to the dispenser, and a step of receiving a fuel supply protocol negotiation response (FuelProtNegoRes) message, which includes information on a second fuel supply protocol selected from among fuel supply protocols commonly applicable between the mobility and the dispenser.

[0279] When a particular communication protocol is selected as a result of communication protocol negotiation, a request message containing information about at least one first fueling protocol applicable to the mobility as a fueling protocol supporting the selected particular communication protocol may be transmitted to the dispenser.

[0280] At this time, the dispenser may select common protocols among the fuel supply protocol applicable to the dispenser and the first fuel supply protocol as fuel supply protocols supporting a specific communication protocol, and transmit the selected common fuel supply protocol (hereinafter referred to as the second fuel supply protocol) to the mobility. At this time, the second fuel supply protocol may be selected based on interoperability and / or compatibility, or may be selected by applying preferences set by the mobility or the dispenser.

[0281] Meanwhile, in another aspect, the dispenser may receive a message from the mobility including information on a first fuel supply protocol applicable to the mobility, select a common fuel supply protocol (second fuel supply protocol) applicable between the mobility and the dispenser among the first fuel supply protocol and the fuel supply protocols applicable to the dispenser, and transmit a message including information on the selected second fuel supply protocol to the mobility. At this time, the dispenser may request information including a list of first fuel supply protocols applicable to the mobility in advance from the mobility.

[0282] Alternatively, if the dispenser first transmits a message to the mobility containing information about its applicable fueling protocols, the mobility may be configured to select a specific fueling protocol from among the commonly applicable fueling protocols and transmit a message containing information about the selected specific fueling protocol to the dispenser. In this case, the mobility may be configured to request information from the dispenser in advance containing a list of applicable fueling protocols.

[0283] According to this embodiment, the objectives, short description, pre-conditions and post-conditions of the fourth use case (UC4) for the fueling protocol negotiation procedure can be defined as shown in Table 9 below.

[0284] TypeDescriptionUse Case NameUC4: "Negotiate Fuel Delivery Protocol"PurposeThe vehicle and the dispenser decide which fuel delivery protocol to use for fuel delivery.Brief DescriptionOnce the communication protocol selection is complete, the vehicle and the dispenser negotiate which fuel delivery protocol to use for fuel delivery. The negotiation begins when the vehicle sends a list of supported protocols, the dispenser selects a common protocol supported by both, and then the vehicle selects its most preferred protocol.Prerequisite: A communication protocol is selected.Subsequent Conditions: The vehicle and the dispenser agree on which fuel delivery protocol to use for fuel delivery.

[0285] According to this embodiment, the content of messages transmitted or received with hydrogen mobility in the fuel supply protocol negotiation stage can be defined by the following Table 10.

[0286] Element NameTypeMeaningfuelProtocolTypeVehicle support fueling protocolfuelingProtocolTypeidxUnsigned integerIndex of the fueling protocolNameStringName of the fueling protocolVerStringVersion of the fueling protocolsubprototStringOptional:Name of the subprotocolprefUnsigned integerPreference of the protocolsLower numbers indicate higher preference

[0287] Information about the fueling protocol included in the fueling protocol negotiation request (FuelProtNegoReq) message may include, as shown in FIG. 12, an index of the fueling protocol (index, idx), a name of the fueling protocol (name), a version of the fueling protocol (version, ver), a sub-protocol of the fueling protocol (sub-protocol, subprot), and a preference for the fueling protocol (preferance, pref). A lower number in the preference may indicate a higher preference. When the fueling protocol negotiation request message is expressed in JSON format, as shown in FIG. 13, the fueling protocols (fuelProts) of the fueling protocol negotiation request message (1300) may include information about a plurality of protocols enclosed in curly brackets. Among the plurality of protocols, a first protocol may be a fueling protocol type (fuelingProtocolType) with an index of 1, a name of ISO 19885:PRHYDE, a subprotocol type 1 (Type1), a version 2024, and a preference 1. And, a second protocol may be another fueling protocol type with an index of 2, a name of ISO 19885:RTR, a version 2024, and a preference 2. Of course, the fueling protocols may include three or more plurality of protocols.

[0288] Additionally, the content of the fueling protocol negotiation response (FuelProtNegoRes) message transmitted or received between hydrogen mobility and the dispenser can be defined by the following Table 11.

[0289] Element Name Type Content / Semantics Index Unsigned integer Optional: Index of the selected protocol Result Enumeration The result of the fueling protocol negotiation. If the negotiation succeeds, 'OK'. If the negotiation fails, 'FAILED_INCOMPAT'.

[0290] As shown in FIG. 14, the fuel supply protocol negotiation response (FuelProtNegoRes) message may include an optional field, index, and information on whether the fuel supply protocol negotiation was successful as a result. In addition, as shown in FIG. 15, the fuel supply protocol negotiation response message (1500), when expressed in JSON format, may be configured to include fields in which the index is 1 and the result is "OK", respectively.

[0291] The content of the message transmitted during the fuel supply protocol negotiation process according to this embodiment can be defined as shown in Table 12 below.

[0292] Index Name Revision Subprotocol Preference 1 PRHYDE2023 TYPE3-T-initial 4 2 PRHYDE2024 TYPE3-T-Special 3 3 RTR-HFP--24 ANN-MPC--55 HMC-FAST1.0-1

[0293] As shown in Table 12, mobility can provide the dispenser with parameter information in the form of a table that includes information about the name, revision date (year) or version, whether a sub-protocol is available, and priority or preference for the supported fueling method or fueling protocol. In Table 12, PRHYDE (PROtocol for heavy-duty HYDrogEn refueling) is proposed by one of the European projects that has been developing a heavy-duty vehicle charging protocol, RTR-HFP is proposed by a type of protocol concept that improves charging efficiency based on real-time communication, and ANN-MPC is proposed by a type of protocol concept that collects and analyzes data from the charging site and applies predictions to actual charging situations.

[0294] Meanwhile, in a variation of the present embodiment, the dispenser can proactively exchange its own fuel supply protocol with the mobility on behalf of the mobility, and can provide the fuel supply protocols supported by the dispenser with priority to the mobility.

[0295] Messages that a dispenser can send to a mobility during the fuel supply protocol negotiation phase are exemplified in Tables 13 and 14 below.

[0296] fueling Protocol IDResultCode2OK

[0297] According to Table 13, the dispenser can select the fueling protocol ID corresponding to index 2 and transmit a response message including the result code OK to the mobility.

[0298] fueling Protocol IDResultCodeFAIL_NO_COMMON_PROTOCOL

[0299] In addition, according to Table 14, if the dispenser fails to find a compatible protocol in the list of fuel supply protocols supported by the mobility received from the mobility, the dispenser may transmit a response message containing information indicating that there is no common protocol, for example, 'FAIL_NO_COMMON_PROTOCOL' or 'FAIL_INCOMPAT', in the ResultCode field to the mobility. According to the examples in Tables 13 and 14, a similar application may be made when the dispenser selects a second communication protocol from among the common communication protocols and responds to the mobility during the fuel supply protocol negotiation phase.

[0300] FIG. 16 is an exemplary diagram illustrating a fueling parameter negotiation procedure of the fueling framework of FIG. 5 and a fueling parameter negotiation request message applicable to its functional blocks. FIG. 17 is an exemplary diagram illustrating a fueling parameter negotiation procedure of the fueling framework of FIG. 5 and a fueling parameter negotiation response message applicable to its functional blocks. And FIG. 18 is an exemplary diagram illustrating a JSON message format of a fueling parameter negotiation request message of FIG. 16 or a fueling parameter negotiation response message of FIG. 17.

[0301] Referring to FIGS. 16 to 18, the fuel supply parameter negotiation procedure may include a process in which the mobility and the dispenser exchange detailed parameters necessary for executing a fueling protocol. The fuel supply parameter negotiation procedure may be referred to as a fuel supply parameter exchange procedure.

[0302] The fuel supply parameter negotiation procedure may include a step of the mobility transmitting a message including information on fuel supply parameters of the mobility side required for a specific fuel supply protocol selected as a result of fuel supply protocol negotiation, for example, a fueling parameter negotiation request (FuelParamNegoReq) message, to the dispenser, and a step of receiving a message including compatibility information on the dispenser side for the fuel supply parameters of the mobility side, for example, a fueling parameter negotiation response (FuelParmNegoRes) message, from the dispenser.

[0303] In another aspect, the fuel supply parameter negotiation procedure may include the steps of receiving a message from the dispenser including information about fuel supply parameters on the dispenser side required for a particular fuel supply protocol selected as a result of the fuel supply protocol negotiation, and transmitting a message including compatibility information on the mobility side for the fuel supply parameters on the dispenser side to the dispenser.

[0304] When a mobility or dispenser receives a message containing information about fuel supply parameters provided by the other party during the fuel supply parameter negotiation process, and accepts the parameters of the message, it may set the "Accepted" field or the parameters in this field to "OK" or "TRUE".

[0305] Additionally, the mobility or dispenser may send the message to the other party with the "Accepted" parameter set to "pending" if it wishes to exchange more parameters to reach an agreement on the fuel supply parameters.

[0306] Additionally, if the mobility or dispenser cannot accept the parameters provided by the counterpart in the last message, the "Accepted" parameter can be set to "FAIL" or "FALSE." If the dispenser returns "Accepted set" as "FALSE," the mobility can terminate the communication or return to the fourth use case (UC4) for the fuel supply protocol negotiation procedure or the third use case (UC3) for the communication protocol negotiation procedure to find an alternative method.

[0307] Mobility and dispensers can reach agreement on all parameters by repeatedly sending and receiving messages and responding to those messages.

[0308] Parameters exchanged between the mobility and the dispenser may include parameters to support fueling method compatibility, parameters for physical characteristics, monitoring parameters, acceptance-related parameters, etc.

[0309] Here, the compatibility support related parameters include pressure class, CHSS category, etc., the physical characteristic parameters include maximum allowable CHSS pressure, maximum allowable CHSS temperature, maximum allowable speed, CHSS volume, etc., the monitoring parameters include current CHSS pressure, current CHSS temperature, etc., and the acceptance related parameters may include information indicating whether it is accepted or not, such as a parameter indicating yes (true) or no (false). The above-mentioned parameters may each be set with information on one of the pre-specified levels or set values ​​and information on different or identical main UCDC levels.

[0310] Meanwhile, the dispenser supports the following parameters:<DIS's parameters> , briefly<DIS's params> ) can transmit an OK message to the mobility indicating that the information about the mobility and the parameters of the mobility have been received and accepted.

[0311] In addition, parameters related to compatibility support may include fueling delivery temperature, selected fueling table, etc., parameters related to physical characteristics may include maximum fuel delivery pressure, maximum fuel delivery temperature, minimum fuel delivery temperature, maximum fuel delivery speed, etc., parameters related to fueling targets may include target SOC, target final CHSS pressure, target final CHSS temperature, target APR, expected fueling duration, etc., monitoring parameters may include current fuel delivery temperature, ambient temperature, etc., and parameters related to acceptance may include parameters such as accepted, etc. The above-mentioned parameters may each be set with information on one of preset levels or set values ​​and information on main UCDC levels that are different or the same.

[0312] In this way, mobility can provide the dispenser with parameters listed in a table format. The listed parameters can include hydrogen mobility parameters compatible with the UCDC level negotiated during the fuel supply protocol negotiation process.

[0313] As described above, once a communication link is established and the communication and fueling protocols are selected during the protocol negotiation phase, the vehicle and dispenser can exchange various parameters to determine whether they can execute compatible fueling procedures. Information necessary for performing a safe and efficient fueling procedure may include compatibility parameters, physical characteristics, fueling objectives, and monitoring parameters.

[0314] Compatibility parameters may include, for example, pressure rating, fuel delivery transmission temperature, etc., physical characteristics may include, for example, maximum CHSS pressure, maximum flow rate, etc., fuel delivery targets may include target SOC, target CHSS pressure, etc., and monitoring parameters may include current CHSS temperature, ambient temperature, etc.

[0315] If compatible parameters cannot be found and fueling cannot proceed, the hydrogen mobility device can return to the communication protocol negotiation stage to attempt negotiation of a different protocol or request that the dispenser stop fueling. Furthermore, in the reverting communication protocol negotiation stage due to a failure in the fueling parameter exchange stage, the hydrogen mobility device, such as the FCEV, can be configured to propose a set of supported protocols to the dispenser, excluding the protocol that failed in the fueling parameter exchange stage.

[0316] According to the fifth use case (UC5) for the fuel delivery parameter negotiation process, the vehicle and the dispenser can negotiate specific parameters for the fuel delivery protocol, share static or dynamic states, and exchange detailed fuel delivery parameters to determine the fuel delivery target. If the fuel delivery parameter negotiation fails due to incompatibility, the fourth use case (UC4) can be returned to select a different fuel delivery protocol, or the third use case (UC3) can be returned to select a different communication protocol. If this error handling is not performed properly, the current communication can be terminated.

[0317] According to the above-described configuration, some fueling protocols can be performed on a non-communicative basis. Some fueling protocols may require unidirectional IrDA. Some fueling protocols may require bidirectional communication. Some fueling protocols may require both bidirectional communication and unidirectional IrDA. Furthermore, some fueling protocols may require a predetermined UCDC level or a higher UCDC level. At least one fueling protocol may be proposed based on the type or type of the hydrogen fuel cell vehicle and the type or type of the dispenser. The proposed fueling protocols may be proposed with different priorities. While considering the priorities of the proposed fueling protocols, the communication protocol and the fueling protocol between the hydrogen fuel cell vehicle and the dispenser may be ultimately determined based on whether the communication protocol required by the fueling protocol is supported by the hydrogen fuel cell vehicle and / or the dispenser. Then, fuel supply parameters can be negotiated under the determined communication protocol and fuel supply protocol.

[0318] In a variation of this embodiment, either the mobility or the dispenser may first transmit fuel supply parameters to the other party, and the other party may respond with a message containing newly reconfigured fuel supply parameters by keeping parameters it accepts among the received fuel supply parameters and changing parameters it does not accept.

[0319] Additionally, mobility and dispensers can conduct parameter negotiations in stages. In this case, mobility and dispensers can first negotiate some parameters, and then negotiate or exchange subparameters of the agreed-upon parameters.

[0320] Additionally, each message containing fuel supply parameters may be configured to be considered as not reaching an agreement if no response message is received within a preset message processing time.

[0321] Table 15 below shows the contents of a message including fuel supply parameters on the mobility side according to this embodiment.

[0322] NameUnitPrecisionRange / ValueTypeMeaningPressure ClassN / AN / A{H35, H70}Static Tank Pressure ClassCHSS VolumeLiter2 decimalsPositive, No-maxStatic Tank CapacityCHSS PressureMPa2 decimalsPositive, No-maxCurrent Pressure of Dynamic TankEmergency PolicyN / AN / A{Terminate,Fallback}Static Emergency Handling Policy

[0323] Table 16 below shows the contents of a message including fuel supply parameters on the dispenser side according to this embodiment.

[0324] NameUnitPrecisionRange / ValueTypeMeaningFuel SupplyTransferTemperatureN / AN / A{H35, H70}Static...Fuel SupplyTemperatureMPa2 decimalsPositive, No-maxDynamicCurrentTankPressureEmergencyPositionN / AN / A{Terminate,Fallback}StaticEmergencyProcessingPosition

[0325] During the fueling parameter negotiation phase, the mobility and the dispenser can generate and transmit a message with a range / values ​​for the fueling parameters that can be supported to the other party. The parameters related to the fueling parameter negotiation can include physical characteristic related parameters (briefly 'physical parameters'), monitoring parameters, safety policy related parameters, acceptance related parameters, etc.

[0326] Here, the physical parameters include receptacle type, pressure class, CHSS category, CHSS type, CHSS capacity, maximum allowable CHSS pressure, maximum allowable CHSS temperature, maximum allowable speed, etc., the monitoring parameters include current CHSS pressure, current CHSS temperature, etc., the safety policy related parameters include emergency policy, safety enforcement level, etc., and the acceptance related parameters may include information indicating whether it is accepted or not, such as a parameter indicating yes (true), no (false), or pending.

[0327] In addition, the physical parameters may include fueling delivery temperature, maximum fuel delivery pressure, maximum fuel delivery temperature, minimum fuel delivery temperature, maximum fuel delivery speed, etc., the monitoring parameters may include current fuel delivery temperature, ambient temperature, etc., the fueling target related parameters may include selected fueling table, target SOC, target final CHSS pressure, target final CHSS temperature, target APR, expected fueling time, etc., and the acceptance related parameters may include parameters such as accepted, etc. The above-mentioned parameters may each be set with information on one of preset levels or set values ​​and information on main UCDC levels that are different or the same from each other.

[0328] In this way, the hydrogen electric vehicle can provide the dispenser with parameters listed in a table format. The listed parameters may include FCEV parameters compatible with the UCDC level negotiated during the fuel supply protocol negotiation phase.

[0329] Meanwhile, if the received fuel supply parameters are compatible with the dispenser after receiving the fuel supply parameter negotiation request message, the dispenser may respond with its own fuel supply parameters by sending a fuel supply parameter negotiation response message with the "result" set to "OK" to the FCEV within a preset message response time. This response message may be implemented as a fuel supply parameter negotiation response message (1800) in JSON format, as illustrated in FIG. 18.

[0330] Additionally, if the dispenser finds that the fuel supply parameters of the vehicle are not compatible after receiving the fuel supply parameter negotiation request message, the dispenser may respond by sending the fuel supply parameter negotiation response message with the "result" set to "Fail" to the hydrogen electric vehicle to indicate the incompatibility with the vehicle, i.e., the hydrogen electric vehicle. The result may indicate a value or information contained in the result code field, and the failure may be expressed as an expression indicating the incompatibility as a failure at a specific time or of a specific attempt, such as 'FAIL_INCOMPAT'.

[0331] Additionally, after receiving the fuel supply parameter negotiation request message, if the hydrogen mobility finds that the fuel supply parameters of the dispenser are incompatible, the hydrogen mobility can indicate the incompatibility to the dispenser by sending an error notification request message with a “reason” set to each predefined error code.

[0332] Table 17 illustrates fuel supply parameters on the mobility side that can be employed in messages used for two-way communication according to the present embodiment.

[0333] Physical Parameters Receptacle Type? Pressure Class H35 / H70 CHSS Category A / B / C / D CHSS Type 1 / 2 / 3 / 4 CHSS Volume? L Maximum allowed CHSS Pressure? MPa Maximum allowed CHSS temp.? ℃ Maximum allowed flow rate? g / s Monitoring Parameters Current CHSS Pressure? MPa Current CHSS Temp.? ℃ Safety Policy Emergency Policy? Safety Enforcement Level? Acceptance Accepted TRUE / FALSE / PENDING

[0334] Table 18 illustrates dispenser-side fuel supply parameters that can be employed in messages used for two-way communication according to the present embodiment.

[0335] Physical Parameters Fueling Delivery Temp. T30 Max Fuel Delivery Pressure? MPa Max Fuel Delivery Temp.? ℃ Min Fuel Delivery Temp.? ℃ Mass Fuel Delivery Flow Rate? g / s Monitoring Parameters Current Fuel Delivery Temp.? ℃ Ambient Temperature? ℃ Fueling Goal Selected fueling Table D1 Target State of Charge (SOC)? % Target Final CHSS Pressure? MPa Target Final CHSS Temperature? ℃ Target APR? MPa / s Expected fueling Duration? ℃ Safety Policy? sAcceptance Accepted TRUE / FALSE / PENDING

[0336] The communication method according to the present embodiment may further include a procedure for renegotiating at least one of the communication protocol and the fuel supply parameters if the fuel supply parameters are incompatible between the mobility and the dispenser as a result of the fuel supply parameter negotiation (see S505 of FIG. 5). The renegotiation procedure may include re-performing the communication protocol negotiation step, the fuel supply protocol negotiation step, and the fuel supply parameter negotiation step described above. For example, the renegotiation procedure may return to the communication protocol negotiation step, perform renegotiation from the communication protocol negotiation step, and sequentially re-perform the fuel supply protocol negotiation step and the fuel supply parameter negotiation step. As another example, the renegotiation procedure may be configured to return to the fuel supply protocol negotiation step, perform renegotiation from the fuel supply protocol negotiation step, and then re-perform the fuel supply parameter negotiation step.

[0337] Additionally, the renegotiation step may be configured to simplify or omit some of the above negotiation steps. Specifically, the renegotiation step may be configured to combine some of the above negotiation steps to negotiate both the communication protocol and the fuel supply protocol.

[0338] Additionally, the renegotiation step may be renegotiated based on a list of communication protocols and fueling protocols other than the communication protocol or fueling protocol selected in the communication protocol negotiation step and the fueling protocol negotiation step. For example, based on the compatibility and / or interoperability information identified in the discovery and pairing steps, the communication protocol and fueling protocol may be renegotiated based on a protocol list that includes previously unselected communication protocols and fueling protocols, based on whether the communication protocol and fueling protocol are mutually supported.

[0339] In addition, the communication method according to the present embodiment may be configured to determine a third communication protocol and a third fuel supply protocol based on a preset policy when the fuel supply parameters are incompatible between the mobility and the dispenser as a result of fuel supply parameter negotiation, and to perform hydrogen fuel supply based on the third communication protocol and the third fuel supply protocol. At this time, the third fuel supply parameters may be determined based on the third fuel supply protocol, and the hydrogen fuel supply process may be performed based on the third fuel supply protocol and the third fuel supply parameters.

[0340] For example, if communication between the mobility and the dispenser is impossible due to changes in the communication environment, the dispenser can fall back to no communication and perform the hydrogen fueling process using a hydrogen fueling protocol based on no communication.

[0341] Additionally, the two-way communication method may perform a step of terminating communication between the dispenser and the mobility if, as a result of fuel supply parameter negotiation, the fuel supply parameters are not compatible between the mobility and the dispenser.

[0342] FIG. 19 is an exemplary diagram illustrating a safety check-in procedure of the fuel supply framework of FIG. 5 and a safety check-in request message applicable to its functional blocks. FIG. 20 is an exemplary diagram illustrating a safety check-in procedure of the fuel supply framework of FIG. 5 and a safety check-in response message applicable to its functional blocks.

[0343] Referring to FIGS. 19 and 20, in the safety check-in procedure, the mobility and the dispenser can mutually verify that all necessary safety conditions have been met before the actual fueling begins by sharing the result using the SafetyCheckInReq message and the SafetyCheckInRes message.

[0344] The Safety Check-In Request (SafetyCheckInReq) message and / or the Safety Check-In Response (SafetyCheckInRes) message may be configured to include a field indicating the safety check-in result for at least one checkpoint as "OK", respectively.

[0345] That is, after receiving a fuel supply parameter negotiation response message from the dispenser, if the fuel supply protocol supports safe check-in, the mobility can initiate the safe check-in phase by sending a safe check-in request message to the dispenser within a message sequence setting time. Furthermore, the dispenser can initiate the safe check-in phase by sending a safe check-in response message to the mobility within a message sequence setting time.

[0346] During the safety check-in phase, the mobility and / or dispenser can check that the nozzle-receptacle is securely fixed, check for leaks, and check the last-minute status before performing the refueling.

[0347] For example, a mobility and a dispenser can exchange messages for coupler checks. The mobility can send a message containing information indicating the results of its coupler check (e.g., mobility: OK) to the dispenser, and the dispenser can send a message containing information indicating the results of its coupler check (e.g., dispenser (DP): OK) to the mobility.

[0348] Additionally, the mobility and the dispenser can exchange messages related to gas leak checks. During the exchange of leak check-related messages, the dispenser can transmit information indicating that the leak check is ongoing to the mobility. Furthermore, the mobility can transmit information indicating that it is waiting for the results of the leak check to the dispenser. Upon completion of the leak check, the dispenser can transmit a message requesting the measured tank volume along with information indicating that the leak check is complete to the mobility.

[0349] Additionally, the dispenser can send a message to the mobility for an immobilized status check, and the mobility can send a message to the dispenser indicating that it is ready for a status check.

[0350] When the mobility reports parameters about the current or immobilization status of the mobility to the dispenser, the dispenser can report parameters about the coupler lock status, leak check status, predicted mobility tank capacity, etc. to the mobility.

[0351] For example, the mobility and / or dispenser may respond to the other party with an 'OK' result if the safety check-in request message is processed successfully, or a 'PENDING' or 'FAILED' result if the safety check-in request message is processed successfully.

[0352] Referring again to Figure 5, the purpose, brief description, prerequisites and follow-up conditions of the use case (UC6) of the Safety Check-in step can be illustrated by the following Table 19.

[0353] Use Case Name UC-6: "Safety Check-In" Purpose The vehicle and dispenser verify that all necessary safety conditions are met and that the communication link is properly paired with the pairing channel before the actual fueling begins. Short Description Once the fueling parameters have been exchanged and the vehicle and dispenser are considered compatible, the vehicle and dispenser perform a safety check and a pairing check to ensure that the fueling is safe and that the communication is stable. Depending on the fueling protocol and the communication physical layer, the safety check may be performed implicitly within the protocol or the physical connection, and this safety check step may be omitted. Preconditions: The necessary fueling parameters are exchanged. Postconditions: The vehicle and dispenser verify that all safety conditions and pairing are correct and are ready to start fueling.

[0354] As previously mentioned, if the fuel supply parameter negotiation step is successfully completed, the fuel supply protocol can perform a safety check-in step. If the communication physical layer is configured to require a pairing procedure, the mobility and dispenser can recheck the pairing before dispensing hydrogen during the safety check-in step. Furthermore, even if the communication physical layer is not configured to require a pairing procedure, the mobility and dispenser can recheck the pairing before dispensing hydrogen during the safety check-in step.

[0355] For example, after receiving information indicating the completion of the phase via a Fueling Parameters Negotiation Response (FuelParamNegoRes) message from the dispenser, if the fueling protocol supports a safety check-in phase, the mobility may transmit a message indicating the start of the safety check-in phase, for example, a Safety Check-In Request (SafetyCheckInReq) message, to the dispenser within a predetermined time interval, for example, a MessageSequenceTimeout.

[0356] As an alternative embodiment, if a message indicating the completion of the fuel supply parameter negotiation phase is transmitted by one of the mobility and the dispenser to the other, that one or the other may transmit a message indicating the start of the safety check-in phase.

[0357] According to this embodiment, messages transmitted and received in the safety check-in phase can be defined based on the contents of each fuel supply protocol specified in a standard such as ISO 19885-3, for example.

[0358] Additionally, according to this embodiment, messages transmitted and received during the safety check-in phase may include a result value of processing the request message as a result element. The result value that may be provided as the result element may include, for example, "OK" for success, "FAILED" for failure, and "PENDING" for other cases.

[0359] If all safety conditions are met when the mobility sends a SafetyCheckInReq message to the dispenser, the message's result value may be set to "OK." Alternatively, if some safety conditions are not yet met when the mobility sends a SafetyCheckInReq message to the dispenser, the message's result value may be set to "PENDING."

[0360] After receiving a safety check-in request message from the mobility, the dispenser can transmit a safety check-in response (SafetyCheckInRes) message with safety check parameters to the mobility within a message response timeout (MessageResponseTimeout).

[0361] If all safety conditions are met when the dispenser sends a safety check-in response message to the mobility, the result value of the message may be set to "OK." Conversely, if some safety conditions are not yet met when the dispenser sends a safety check-in response message to the mobility, the result value of the message may be set to "PENDING."

[0362] If a safety check-in response message with the result element's value set to "PENDING" is received from the dispenser, the mobility may send another safety check-in request message to the dispenser within the message response time limit.

[0363] Additionally, if the dispenser receives a safety check-in request message from the mobility with the result element's value set to "PENDING", the dispenser may send another safety check-in request message to the mobility within the message response time limit.

[0364] When a mobility or dispenser cannot confirm all safety conditions within a given time, for example, within the use case safety check-in timeout (UCSafetyCheckInTimeout), it can send an error notification request (ErNotifReq) message to the other party with the "reason" field set to an appropriate error code.

[0365] Meanwhile, the mobility or dispenser can transmit a request message to the other party indicating the start of a safety check-in, and the other party can reply with a response message to the request message for a safety check-in within a predetermined time period.

[0366] Once the aforementioned safety check-in steps are completed, fueling can begin. During fueling, the mobility and dispenser can exchange information to monitor various status parameters to ensure safe and efficient fueling. If necessary, either the mobility or dispenser can send control messages to control the fueling process or request action from the other party to address safety-related conditions. The parameters and commands to be exchanged may vary depending on the actual fueling protocol.

[0367] In this way, after the fuel supply parameters have been exchanged and the mobility and dispenser are confirmed to be compatible, the mobility and dispenser can perform a safety check to ensure safe fuel supply. Depending on the fuel supply protocol, the safety check may be implicitly performed within the protocol, and depending on the implementation, the safety check step may be omitted.

[0368] Meanwhile, in one alternative embodiment, the safety check-in step may be executed prior to the fuel supply parameter negotiation step, if the safety check-in step performs a minimum status check, i.e., a check of safety elements including whether the nozzle-receptacle is engaged, the engagement status, etc.

[0369] Additionally, in one alternative embodiment, if the safety check-in step performs a minimum status check, i.e., a check of safety elements including whether the nozzle-receptacle is engaged, the engagement status, etc., the remaining safety elements not checked in the safety check-in step can be negotiated and checked in the fuel supply parameter negotiation step.

[0370] Additionally, in one alternative embodiment, when the safety check-in step performs a minimum status check, i.e., a check of safety elements including whether the nozzle-receptacle is engaged, the engagement status, etc., the remaining safety elements not checked in the safety check-in step may be monitored and checked in the monitoring and control step following the safety check-in step. In this case, the safety elements may be monitored and checked in the monitoring and control step independently of or regardless of whether they are negotiated and checked in the fuel supply parameter negotiation step.

[0371] Additionally, in one alternative embodiment, a plurality of safety elements, including safety elements checked in the safety check-in phase, may be negotiated and checked in the fuel supply parameter negotiation phase.

[0372] Additionally, in one alternative embodiment, multiple safety elements, including those checked during the safety check-in phase, may be monitored and checked during the monitoring and control phase. The safety elements may be monitored and checked during the monitoring and control phase independently of or independently of those negotiated and checked during the fuel supply parameter negotiation phase.

[0373] FIG. 21 is an exemplary diagram illustrating the monitoring and control procedure of the fuel supply framework of FIG. 5 and the monitoring and control request message applicable to its functional blocks. FIG. 22 is an exemplary diagram illustrating the JSON message format of the monitoring and control request message of FIG. 21. FIG. 23 is an exemplary diagram illustrating the monitoring and control procedure of the fuel supply framework of FIG. 5 and the monitoring and control response message applicable to its functional blocks. And FIG. 24 is an exemplary diagram illustrating the JSON message format of the monitoring and control response message of FIG. 23.

[0374] Referring to FIGS. 21 to 24, in the monitoring and control procedure, the mobility and / or dispenser can monitor the fuel supply status through a fueling loop request (FuelLoopReq) message and a fueling loop response (FuelLoopRes) message, and control the fuel supply process when necessary.

[0375] The FuelLoopReq message may include information or fields for initiating an action for fuel supply. For example, the FuelLoopReq message (2200) may include information indicating whether at least one preset action is to be performed, as illustrated in FIG. 21, and information indicating a reason for at least one action.

[0376] Additionally, as shown in FIG. 22, the fuel supply loop request message (2200) can be expressed in JSON format and can be configured to start hydrogen fuel supply to a hydrogen electric vehicle through information preset in the action field, such as “start.”

[0377] The FuelLoopRes message may include information indicating the status, reason, and result of the current operation, as illustrated in FIG. 23. In addition, the FuelLoopRes message (2400) expressed in JSON format, as illustrated in FIG. 24, may include information indicating that the current status is fueling in its status field (e.g., 'fueling' or 'fuelling'), and may include information indicating that the monitoring result and control status are normal in its result field (e.g., 'OK').

[0378] Once all safety checks are confirmed, the vehicle and dispenser can begin refueling according to the pre-selected refueling protocol using the given parameters. During refueling, the vehicle and dispenser can exchange various measurement data to monitor the fueling status and detect safety-critical incidents as quickly as possible.

[0379] Additionally, the mobility can send specific commands to the dispenser to control fueling steps, such as starting and stopping fueling. In this case, the mobility can use UDP with DTLS for communication to support black-channel communication. Black-channel communication refers to communication that applies the black-channel principle, which ensures secure communication despite the output characteristics of the communication channel having unsecured or application-unrelated properties.

[0380] To explain the monitoring and control steps in more detail, for example, the mobility including the mobility can transmit a message to the dispenser to initiate fuel supply control, and in response, the dispenser can transmit a message including confirmation information (e.g., OK) to the mobility.

[0381] Additionally, the mobility can send a message to the dispenser containing information about its fueling loop (e.g., x, y, z), and the dispenser can provide the mobility with a message containing information about its fueling loop corresponding to the mobility's fueling loop (e.g., a, b, c).

[0382] Additionally, the mobility may transmit a fuel supply control request message to the dispenser that includes information to slow down or reduce the amount of fuel supplied, and the dispenser may transmit a response message to the mobility that includes information indicating a decrease in the fuel supply status or a decrease in speed (e.g., slowing).

[0383] Additionally, the mobility can transmit a fuel supply control request message requesting a stop of fuel supply to the dispenser, and the dispenser can transmit a fuel supply status response message including information on stopping or stopping fuel supply (stopping / stopped) to the mobility.

[0384] In this way, during the monitoring and control phase, the mobility and dispenser can continuously or periodically exchange parameters related to the fuel supply status. The mobility can transmit current tank temperature, current tank pressure, etc. to the dispenser, and the dispenser can provide the mobility with parameters related to the start, stop, ramping up, ramping down of fuel supply, current injection pressure, and future fuel supply plans.

[0385] Request messages related to monitoring and control procedures transmitted from the mobility to the dispenser may include information or parameters related to starting, pausing, resuming, and terminating fuel supply. Additionally, messages related to reporting transmitted from the mobility to the dispenser may include information or parameters related to current tank temperature, current tank pressure, and the like.

[0386] Messages related to reporting transmitted from the dispenser to the mobility may include information or parameters such as status information, current ambient temperature, current pressure ramp rate (PRR [Mbar / min]), deliver fuel flow rate (g / sec]), current fuel delivery temperature, pre-cooling temperature, current fuel delivery pressure, whether in use before full charge (full charge), whether in use of a cooled dispenser, whether in use of a fallback, reason for fueling stop, and current amount of hydrogen delivered.

[0387] Additionally, messages related to target parameter updates transmitted from the dispenser to the mobility may include information or parameters regarding target final tank pressure, target final tank temperature, target fuel supply APR, target SOC, current SOC, estimated remaining duration, etc.

[0388] The purpose, brief description, prerequisites, and follow-up conditions of the seventh use case (UC7) for the monitoring and control procedure, i.e., the fueling control and monitoring procedure, can be defined as shown in Table 20 below.

[0389] Use Case Description: UC7: "Monitoring and Control" Purpose: The vehicle and dispenser monitor the fuel supply status and control the fuel supply if necessary. Brief Description: Once all safety checks are verified, the vehicle and dispenser begin fueling according to the selected fueling protocol using the given parameters. During fueling, the vehicle and dispenser exchange various measurement data to determine the fuel supply status and detect safety-critical incidents as early as possible. The vehicle can issue specific commands to the dispenser to control the fueling process, such as starting and stopping the fueling. UDP with DTLS is used for communication to support black-channel communication. Prerequisite: All safety checks are verified, and the vehicle and dispenser are ready for fueling. Postrequisite: The fueling is completed successfully.

[0390] As described above, the fuel supply protocol can perform a monitoring and control phase after the safe check-in phase is successfully completed. The monitoring and control phase may be referred to as the fuel supply control and monitoring phase. Meanwhile, when TCP is used in the monitoring and control procedure, i.e., when the safe check-in response message or the safe check-in phase by the fuel supply protocol is omitted, the mobility can transmit a fueling loop request message to the dispenser within a message sequence setting time after receiving a fueling parameter negotiation response message from the dispenser. The request message or response message related to the fueling loop can be transmitted as a DTLS message.

[0391] If the safety check-in phase is omitted, and the fuel supply parameter negotiation phase is successfully performed, the monitoring and control phase can be performed. While the monitoring and control phase is being performed, the dispenser can perform all necessary steps to supply fuel to the mobility. When the TCP specification is used in the fuel supply control and monitoring use case, the mobility can transmit a message, such as a fuel supply loop request (FuelLoopReq) message, to the dispenser within a predetermined time interval, such as a message sequence timeout (MessageSequenceTimeout), after receiving a safety check-in response (SafetyCheckInRes) message or, in an embodiment where the safety check-in phase is omitted, a fuel supply parameter negotiation response (FuelParamNegoRes) message.

[0392] When the aforementioned black channel is used, after sending a Safety Check-In Response message or, if the Safety Check-In phase is omitted, a Fuel Supply Parameters Negotiation Response message, the mobility as a client and the dispenser as a server may initiate a DTLS 1.3 handshake following certain rules (e.g., RFC 9147) with session resumption using a new session ticket (NewSessionTicket). The new session ticket may be received from the dispenser. 0-RTT may not be used for DTLS session resumption.

[0393] After the DTLS 1.3 handshake is successfully finished, the mobility can send a message to the dispenser requesting the start of the monitoring and control phase within a predetermined time interval, for example, a FuelLoopReq message.

[0394] Both the Fuel Loop Request message and its response message, the Fuel Loop Response (FuelLoopRes) message, can be transmitted in compliance with the DTLS message specification. In addition, additional requirements for the black channel method may be added. The Fuel Loop Request message can be implemented based on the definitions of each fueling protocol.

[0395] The fueling protocol includes static or dynamic data within the fueling loop request message and fueling loop response message. The static or dynamic data can be specified to monitor fueling status and exchange safety-related information.

[0396] The element names included in the fuel supply loop request message may include actions, reasons, etc., and may be defined as exemplified in Table 21 below. Elements not shown in Table 21 below may be specified by each fuel supply protocol standard, such as a given standard, for example, ISO 19885-3.

[0397] Element NameTypeMeaningAction(action)actionTypeOptional: The action that the vehicle requests from the dispenser - start - stop - Any custom actions defined by the fueling protocolReasonreasonTypeOptional: The reason for the action request

[0398] In the seventh use case (UC7) of the monitoring and control procedure, the element names included in messages transmitted and received between the mobility and the dispenser, such as the FuelLoopRes message, may include status, reason, result, etc., and may be defined as in Table 23 below. Elements not shown in Table 22 below may be specified by each fueling protocol standard, such as ISO 19885-3, for example.

[0399] Element NameTypeMeaningStatusStatusTypeOptional: - preparing - precooling - fueling - standby - faulted - ramping-up - ramping-down - stopping - finished - stopped_error - stopped_requested - stopped_unknown - Any custom status codes defined by fueling protocolReasonReasonTypeOptional: Reason for stopping when the fueling is stopped abnormallyResultResultTypeResult of processing the request message. 'OK' if successful, 'FAILED' otherwise.

[0400] When a mobility sends a fueling loop request message to a dispenser, the dispenser may be expected to perform an action. The mobility may send the message with "action" set to a desired action code, which may be defined by the fueling protocol. After receiving a fueling loop request message from a mobility, for example, a fueling loop request message with "action" set to "start," when the dispenser is ready to start, the dispenser may initiate the fueling procedure using a negotiated method and send a fueling loop response message to the mobility with "result" set to "OK." Additionally, after receiving a fueling loop request message from a mobility, for example, a fueling loop request message with "action" set to "start", if the dispenser is not ready to start, the dispenser may send a fueling loop response message with "result" set to "pending" to the mobility. Additionally, after receiving a fueling loop request message from a mobility, for example, a fueling loop request message with "action" set to "stop", if the dispenser is ready to stop, the dispenser may stop the fueling procedure as defined in the fueling protocol and send a fueling loop response message with "result" set to "ONGOING" to the mobility.

[0401] Additionally, after receiving a fueling loop request message from the mobility, for example, a fueling loop request message with "action" set to "stop", if the dispenser is ready to stop, the dispenser can immediately stop the fueling procedure and send a fueling loop response message with "result" set to "OK" to the mobility.

[0402] Additionally, after receiving a fuel supply loop request message from the mobility, the dispenser can transmit a fuel supply loop response message to the mobility within a predetermined time interval, such as a message sequence timeout (MessageSequenceTimeout).

[0403] The dispenser may send a fuel supply loop response message to the mobility with "result" set to "OK" if the received fuel supply loop request message was successfully processed. Alternatively, the dispenser may send a fuel supply loop response message to the mobility with "result" set to "FAILED" or another appropriate error code if the received fuel supply loop request message was not successfully processed.

[0404] The dispenser may send a fueling loop response message to the mobility with "status" set to a table similar to Table 22 or one of the support codes specific to the fueling protocol. Additionally, the dispenser may send a fueling loop response message to the mobility with "status" set to "finished" when the fueling is complete (done) and the intended fueling goal is achieved.

[0405] Additionally, the dispenser may send a fueling loop response message to the mobility with "status" set to "stop_error" and "reason" set to an appropriate reason code if fueling is stopped for any error-related reason.

[0406] The dispenser may send a fuel loop response message to the mobility with "status" set to "stopping" if the "action" of the most recent fuel loop request message was set to "stop" and fueling has not been completely stopped.

[0407] Additionally, the dispenser may send a fueling loop response message to the mobility with "status" set to "stopped_requested" if the "action" of the most recent fueling loop request message was set to "stop" and fueling has been completely stopped.

[0408] When a mobility sends a fueling loop request message with "action" set to "stop" to a dispenser and receives a fueling loop response message with "status" set to "stopping" from the dispenser, the mobility may send a fueling loop response message with "action" set to "stop" to the mobility.

[0409] If a fueling loop response message is received from the dispenser and the fueling is not finished yet, the mobility can send a fueling loop request message to the dispenser within a predefined time interval, such as a message sequence timeout (MessageSequenceTimeout).

[0410] In the event of a safety-critical incident, either the mobility or the dispenser can immediately send an EmergencyReq message to the other party, which can then stop the refueling process and close the communication.

[0411] The above fuel supply control and monitoring steps have been described with a focus on an embodiment in which the mobility requests the start of each step and the dispenser responds. However, the present invention is not limited thereto. In an alternative embodiment of the present invention, the fuel supply control and monitoring steps may be performed by either the mobility or the dispenser first transmitting a message requesting the start of the fuel supply control and monitoring step, and the other party responding to the message requesting the start of the fuel supply control and monitoring step.

[0412] In the fuel supply control and monitoring phase, a message transmitted by either the mobility or the dispenser may include a monitoring request regarding the status of the hydrogen fueling procedure. The response message from the other party may include information on the requested monitoring target status. In this case, the status and related parameters that may be the target of the monitoring request may include a set of parameters exchanged in the fueling parameter negotiation phase. The status and related parameters that may be the target of the monitoring request may include the status and parameters of the mobility or the dispenser. The status and related parameters that may be the target of the monitoring request may include the fueling status and / or related parameters of the mobility and / or the dispenser that are changed or maintained by the hydrogen fueling procedure.

[0413] Additionally, the status that may be the subject of a monitoring request may include the status and / or information regarding the fueling procedure itself, which involves the fueling from the dispenser to the vehicle. For example, the fueling procedure may include information such as whether it is ongoing, paused, terminated, and / or, if stopped / terminated, whether it was stopped due to an error or finished due to the achievement of a goal.

[0414] After completing the hydrogen fueling process while performing the aforementioned monitoring and control procedures, and before terminating the session and disconnecting the nozzle from the vehicle, the vehicle and the dispenser can each verify that all safety conditions are met through a safety check-out procedure, use case 8 (UC8, see S508 in FIG. 5 ). This safety check-out procedure is optional, but can be configured to define a dedicated safety check step in the fueling protocol to ensure the desired level of safety in a precise and explicit manner.

[0415] FIG. 25 is an exemplary diagram illustrating the safety check-out procedure of the fuel supply framework of FIG. 5 and a safety check-out request message applicable to its functional blocks. FIG. 26 is an exemplary diagram illustrating the safety check-out procedure of the fuel supply framework of FIG. 5 and a safety check-out response message applicable to its functional blocks.

[0416] A safe checkout procedure applicable to the communication method for hydrogen fueling of the present embodiment may be performed as follows. Specifically, the mobility and dispenser can verify, through the safe checkout step, that all necessary safety conditions have been met before disconnecting the dispenser nozzle from the outlet. In other words, the mobility and dispenser can verify that it is absolutely safe for the user or operator to disconnect the nozzle from the mobility after fueling is complete.

[0417] For example, as shown in FIGS. 25 and 26, after the mobility receives a fueling loop response message from the dispenser in which the "result" is set to "OK", the "status" is set to "finished", or the prefix is ​​"stopped", and if the hydrogen fueling protocol supports safe checkout, the mobility may initiate safe checkout. At this time, the mobility may transmit a safe checkout request (SafetyCheckOutReq) message to the dispenser within a message sequence setting time, and the dispenser may transmit a safe checkout response (SafetyCheckOutRes) message to the mobility within a message sequence setting time, and the safe checkout process may be performed through these messages for the safe checkout procedure.

[0418] The mobility and dispenser can repeatedly report their status to each other until all safety checks are completed. If the communication process for hydrogen fueling does not require this final safety check, the use case for safety checkout can be omitted.

[0419] To elaborate further on the aforementioned safe checkout procedure, for example, the mobility may transmit a message to the dispenser containing information about the result of a coupler check (e.g., OK), and the dispenser may transmit a message to the mobility containing information indicating that a coupler check is in progress (e.g., Ongoing).

[0420] Additionally, the mobility can transmit a message containing coupler inspection result information (e.g., OK) back to the dispenser, and the dispenser can transmit a message containing coupler inspection completion information (e.g., Done) to the mobility.

[0421] When the above-described coupler inspection completion information is confirmed to have been completed normally, the nozzle of the dispenser can be separated from the receptacle of the mobility by the user or operator.

[0422] During the aforementioned safe checkout step, the report message transmitted from the dispenser to the mobility may include information or parameters regarding the coupler unlock status. The coupler unlock status information may include information regarding locked, unlocked, icing, or problem.

[0423] The purpose, brief description, prerequisites, and postrequisites of the use case (UC8) of the Safety Check-out step can be defined as shown in Table 23 below.

[0424] Use Case Name: UC8: "Safe Checkout" Purpose: The vehicle and dispenser verify that all necessary safety conditions have been met before removing the nozzle from the receptacle. Short Description: After fueling is complete, the vehicle and dispenser verify that it is absolutely safe for the user or operator to remove the nozzle from the vehicle. The vehicle and dispenser repeatedly report their status until all safety checks are completed. This use case can be omitted if the fueling protocol does not require these safety checks at the end. Precondition: Fueling is complete. Postcondition: It is safe to remove the nozzle from the receptacle.

[0425] A safety checkout step can be performed after fueling is finished, terminating the session, and before unplugging the nozzle from the vehicle to ensure that the vehicle and dispenser have met safety conditions. The safety checkout step is optional, but a dedicated safety checkout procedure can be defined in the fueling protocol to ensure the desired level of safety in a precise and explicit manner. Once the fueling procedure associated with the monitoring and control steps has been successfully completed, the fueling protocol can perform the safety checkout step. The information exchange during the safety checkout step can be used for diagnostics and accountability purposes when a safety-related incident occurs. Regardless of whether a safety checkout is performed, a fueling protocol compliant with ISO 19885-2 can define a set of safety conditions that must be verified between the vehicle and the dispenser before unplugging the nozzle.

[0426] After receiving a fueling loop response message from the dispenser with "Result" set to "OK" and "status" prefixed with "finished" or "stopped", if the fueling protocol supports safe checkout, the mobility may send a message requesting the start of the safe checkout phase, for example a SafetyCheckOutReq message, to the dispenser over the TLS channel within a predetermined time interval.

[0427] If the TCP / TLS channel is disconnected at this point, the mobility can re-establish the TCP / TLS channel with the dispenser. The re-establishment process can be initiated by a TLS-resumption handshake using a new session ticket received before sending the Secure Checkout Request message.

[0428] As an alternative embodiment, a message requesting the initiation of a secure checkout phase may be transmitted by either the mobility or the dispenser to the other party. The other party may then perform the secure checkout phase by responding to the message requesting the initiation of the secure checkout phase.

[0429] According to this embodiment, the messages transmitted or received in the safe checkout step can be defined based on the contents of each fuel supply protocol stipulated in a standard such as ISO 19885-3, for example.

[0430] According to this embodiment, messages transmitted or received during the secure checkout phase may include a result value of processing the request message as a result type. The result value that may be provided as a result type may include, for example, "OK" if secure checkout succeeds, "FAILED" if it fails, and "PENDING" in other cases.

[0431] When a mobility sends a safe checkout request message to a dispenser, if the mobility confirms that all safety conditions have been met, the result value of the message may be set to "OK." Additionally, if some safety conditions have not yet been met when the mobility sends a safe checkout request message to the dispenser, the result value of the message may be set to "PENDING."

[0432] After receiving a safe checkout request message from a mobility, the dispenser can respond to the mobility with a safe checkout response message with safe check parameters within a message sequence time limit. If the dispenser confirms that all safety conditions are met when transmitting the safe checkout response message to the mobility, the result value of the message can be set to "OK." Additionally, if some safety conditions are not yet met when the dispenser transmits the safe checkout response message to the mobility, the result value of the message can be set to "PENDING."

[0433] If the mobility receives a safe checkout response message with a result value set to "PENDING" from the dispenser, the mobility may send another safe checkout request message to the dispenser within the message sequence timeout. If the mobility receives a safe checkout request message with a result value set to "PENDING", the dispenser may send another safe checkout request message to the mobility within the message sequence timeout.

[0434] When a mobility or dispenser cannot confirm all safety conditions within a given time, for example, within the use case safety checkout time limit, it can send an error notification request (ErrNotifReq) message to the other party with the "reason" field set to an appropriate error code.

[0435] Meanwhile, as an alternative embodiment, either the mobility or the dispenser can transmit a request message indicating the start of a safe checkout to the other party, and the other party can respond with a response message to the request message for a safe checkout within a predetermined time period.

[0436] When the fuel supply is completed and the nozzle is safely disconnected according to the hydrogen fuel supply protocol described above, or when a non-safety-critical issue occurs during another use case, the ninth use case (UC9) for the termination procedure can be performed.

[0437] Meanwhile, some of the safety conditions checked or monitored in the aforementioned safety check-in step, monitoring and control step, and safety check-out step are exemplified in Table 19, etc., but the following may be additionally or supplementarily considered.

[0438] That is, the safety conditions may include safety-related factors on both sides of the mobility for hydrogen fueling and the hydrogen charger or dispenser, and / or the fastening status of the nozzles and receptacles on both sides for initiating hydrogen fueling. In addition, on the hydrogen mobility side, the pressure and temperature inside the hydrogen tank may be further included. In addition, on the hydrogen charging station side, the temperature inside the cylinder, charging pressure, ambient temperature, etc. may be included. In addition, the safety conditions on the connection and fueling loop on both sides may include the nozzle-receptacle fastening status, i.e., whether it is fastened, the fastening status, the leakage status, etc. Here, the nozzle-receptacle fastening status may include information on whether it is in a suitable and / or sufficient state to perform the hydrogen fueling procedure.

[0439] FIG. 27 is an exemplary diagram illustrating the termination procedure of the fuel supply framework of FIG. 5 and the termination request message applicable to its functional blocks. FIG. 28 is an exemplary diagram illustrating the JSON message format of the termination request message of FIG. 27. FIG. 29 is an exemplary diagram illustrating the termination procedure of the fuel supply framework of FIG. 5 and the termination response message applicable to its functional blocks. And FIG. 30 is an exemplary diagram illustrating the JSON message format of the termination response message of FIG. 29.

[0440] The termination procedure that can be employed in the communication method for hydrogen fueling of the present embodiment may be the final step of the hydrogen fueling procedure, whereby the mobility and the dispenser may exchange information on the fueling results regarding the fueling performance and method, and / or information on the reason for an unexpected interruption of the fueling, thereby completing all procedures for hydrogen fueling. The ninth use case (UC9, see S509 of FIG. 5) for the termination procedure may also be configured to handle tasks related to non-safety-critical issues that occur.

[0441] For example, as shown in FIGS. 27 to 30, after the mobility receives a safe checkout response message from the dispenser with the "result" set to "DONE", or a fuel supply loop response message with the "status" set to "finished" or the prefix "stopped", the mobility may transmit a TerminateReq message to the dispenser and receive a TerminateRes message from the dispenser, thereby performing a termination procedure.

[0442] More specifically, regarding the ninth use case of the termination procedure, as shown in FIGS. 27 and 28, the mobility can transmit a termination request message (2800) to the dispenser, which includes fields and parameters and / or values ​​for tank pressures, tank temperature, fuel supply amount, state of charge (SOC), and reason for termination.

[0443] Additionally, the mobility can transmit a confirmation request message for the completion of fuel supply to the dispenser, and the dispenser can transmit a goodbye message to the mobility as a response message to the confirmation request message.

[0444] Additionally, as shown in FIGS. 29 and 30, the mobility may receive a termination response message (3000) from the dispenser, including fields and parameters and / or values ​​for average pressure rise rate (APR), time taken for fuel supply (Duration), amount of fuel supplied (Amount), state of charge (SOC) of the vehicle tank, and result. The dispenser may transmit a response message to the mobility, including information about the amount of hydrogen supplied (e.g., X gram), in response to a query message or termination request message from the mobility.

[0445] Meanwhile, after the fueling is completed and safety inspections are confirmed, the mobility and dispenser may exchange at least some bookkeeping information regarding the hydrogen fueling session during the termination phase. The mobility and dispenser may exchange summary information regarding the hydrogen fueling session before completing the termination process.

[0446] Book-keeping information may include all information related to hydrogen fueling recorded in the mobility or dispenser according to preset rules or policies throughout all fueling sessions for hydrogen fueling and prior to completion of Use Case 9 (UC9) of the termination procedure.

[0447] The ledger information or summary information may include information such as how much fuel was dispensed, what reports were generated, etc. Additionally, the reporting message transmitted from the mobility to the dispenser may include information or parameters regarding the current tank temperature and current tank pressure, and the reporting message transmitted from the dispenser to the mobility may include information regarding the final SOC, the final average fueling rate (APR), the final measured tank pressure, the actual fueling time, and the actual amount of hydrogen fueled.

[0448] Once all necessary information for a fueling session has been saved, the fueling session can be completely terminated.

[0449] Once the fueling is successfully finished and optionally all safety conditions are verified, the mobility and dispenser can perform the ninth use case (UC9) for the termination procedure (see S509 in FIG. 5).

[0450] The purpose, brief description, prerequisites, and follow-up conditions of Use Case 9 (UC9) for the Termination procedure can be defined as illustrated in Table 24 below.

[0451] DescriptionUse Case NameUC9: "Termination"PurposeThis is the final stage of a fueling session, where the vehicle and dispenser exchange information about the fueling results, including fueling performance and method, and the reason for any unexpected fueling interruption. This use case also handles housekeeping during the termination stage in case a non-safety-critical issue occurs.Brief DescriptionAfter fueling is complete and safety checks have been confirmed, the vehicle and dispenser exchange ledger information about the fueling session.In case a non-safety-critical issue occurs, this use case allows the vehicle and dispenser to exchange summary information about the fueling session before leaving.Preconditions: Fueling is complete and it is safe to pull the nozzle, or a non-safety-critical issue occurred during another use case.Successor Conditions: Information about the fueling session is saved and the fueling session is completely terminated.

[0452] If the safe check-out use case is skipped after receiving a safe check-out response message with result set to "DONE" or a fueling loop response message with "status" set to a prefixed value of "finished" or "stopped", the mobility can send a terminate request message to the dispenser. The details of the terminate request message can be defined in each fueling protocol specification. For example, the parameters exchanged between the mobility and the dispenser within the terminate request message can be defined differently for each individual fueling protocol. The element names included in the terminate request message can include tank pressure (tank_press), tank temperature (tank_temp), amount, state of charge (SOC), reason, etc., and can be defined as exemplified in Table 26 below. Elements not exemplified in Table 25 below can be specified by each fueling protocol specification, such as ISO 19885-3, for example.

[0453] Element NameTypeMeaningTank PressureFinal Tank PressureTank TemperatureFinal Tank TemperatureQuantityOptional: Amount of hydrogen filledFill QuantityOptional: Final fill quantity measured on the vehicleReasonReasonTypeReason for termination from the vehicle's perspective. "Complete" if indicated by the dispenser, "stopped_user" if the user requested a stop, "Complete" if the fueling target was achieved, "Unknown" otherwise. Other reason codes can be defined depending on the fueling protocol.

[0454] Upon receiving a termination request message from the mobility, the dispenser may reply to the mobility with a termination response message within a specified time interval, such as the message response timeout (MessageResponseTimeout). The details of the termination response message may be defined in each fueling protocol specification. For example, the parameters exchanged between the mobility and the dispenser included in the termination response message may be defined differently for each individual fueling protocol. The names of the elements included in the termination response message may include average pressure ramping rate (APR), fueling duration, amount, state of charge (SOC), result, etc., as exemplified in Table 27 below. Elements not exemplified in Table 26 below may be specified by a fueling protocol specification, such as ISO 19885-3, for example.

[0455] Element NameTypeMeaningAverage Pressure Rise Rate-Optional: Average pressure rise rateDuration-Optional: Fuel delivery durationQuantity-Optional: Amount of hydrogen deliveredFill Amount-Optional: Final charge amount measured at the dispenserResultResultType-

[0456] Meanwhile, as an alternative embodiment, a message requesting the start of a termination phase may be transmitted by either the mobility or the dispenser to the other party. The other party may then perform the termination phase by responding to the message requesting the start of the termination phase. Examples of communication data between the dispenser / charging station and the mobility / vehicle for some of the aforementioned use cases (UC5 to UC9) are as shown in Table 27 below.

[0457] UC classificationCharging station → vehicleVehicle → charging stationFuel supply parameter negotiationCheck communication transmissionCharging protocolHydrogen supply (cooling) temperatureTarget charging pressureTarget expected tank temperature after chargingTarget charge amount (SOC %)Target charge timeStandby temperatureCheck communication transmissionMaximum operating pressureMaximum operating temperatureMaximum operating flowTank temperatureTank pressureTank volumeVehicle charging pressure (350 / 700, etc.)Safety checkNozzle-receptacle connectionHydrogen storage system leak check resultCharging station predicted vehicle tank volume (check usage map suitability)Tank temperatureTank pressureTank volumeMonitoring and controlHydrogen supply (cooling) temperatureTarget charging pressureTarget expected tank temperature after chargingTarget charge amount (SOC %)Standby temperatureTarget charging speedActual charging speedTarget charging timeActual charging timeCharging flow rateCharging status (start / charging / stop / pause)Communication statusWhen charging is stopped Reason (Normal termination / Insufficient charging station pressure / Communication error) Top-off status Whether cold dispenser is in use Whether fallback is in progress Tank temperature Tank pressure Tank volume Request to stop charging Safety checkout Whether nozzle-receptacle can be separated (removable / icing, etc.) Tank temperature Tank pressure Tank volume Termination Target charge amount Actual charge amount Target charge speed Actual charge speed Target charge pressure Actual charge pressure Target tank temperature Actual tank temperature Target charge time Actual charge time

[0458] FIG. 31 is an example diagram showing the error handling procedure of the fuel supply framework of FIG. 5 and the JSON message format of an error handling message applicable to its functional block. The tenth use case (UC10) of the error handling procedure in the communication method for hydrogen fuel supply of the present embodiment is a case for handling a situation in which a non-critical error to safety occurs by terminating the fuel supply procedure similar to a normal termination or suddenly stopping communication.

[0459] Error handling procedures may define error conditions associated with the fueling protocol, provide detection criteria, and include response processes, including notification, termination, and fallback mechanisms, when an error condition is detected.

[0460] Error handling procedures can be applied when a non-safety-critical error occurs and further communication is impossible. That is, the mobility and dispenser can handle non-safety-critical errors occurring at any time during fuel delivery through error handling procedures. In other words, the mobility and dispenser can immediately stop fuel delivery, temporarily suspend the previously running use case, and then proceed to the termination use case (UC9).

[0461] If the mobility detects an event for a non-safe critical error, the mobility may notify the dispenser of the reason for termination via a Terminate Request (TerminateReq) message (3100) and terminate the current fueling session or communication session. The dispenser may terminate the current communication session in response to the Terminate Request message. If further communication is not possible, the current session may be terminated without further notification.

[0462] A message that can be used for communication for error handling may include a termination request message (3100) as illustrated in FIG. 31. The termination request message (3100) may include a header (header, hdr) and a message (message, msg) body. The header may include attributes for a timestamp (timestamp, ts), a session identifier (session ID, sid), and a message identifier (message ID, mid). The message identifier (mid) attribute may include information indicating that it is a termination request message, for example, "TerminateReq."

[0463] Additionally, if a non-safety-critical error is detected in the mobility and the communication channel continues to operate, the mobility may send a termination request message (3100) to the dispenser with the "action" attribute set to "stop" in the message body and the "reason" attribute set to an appropriate reason or reason code. The appropriate reason or reason code may include information such as "message is corrupted."

[0464] The aforementioned termination request message may be sent in error situations of non-critical communication errors, system errors, and qualitative errors, except in cases where recovery is not possible.

[0465] In other words, for successful refueling, communication must exhibit expected behavior according to the protocol, and refueling behavior must fall within the acceptable range of the refueling protocol. However, in reality, various abnormal events can occur. Some errors are trivial and easily handled, while others are unrecoverable and prevent refueling from proceeding. Therefore, the error handling phase defines non-safety-critical error conditions and provides example error conditions and possible responses.

[0466] Examples of communication errors include a loss of communication, unrecognizable received data due to encoding or syntax errors, or data falling outside of acceptable ranges. System errors may include instances where the dispenser or mobility device detects a critical system error. Qualitative errors may include instances where the quality of communication performance does not meet requirements, or where the quality of data integrity or accuracy does not meet requirements.

[0467] In the communication method for hydrogen fuel supply of the present embodiment, the error handling process can perform the following specific error handling steps for the above-described error conditions.

[0468] First, if a non-critical error occurs and further communication is no longer possible, the mobility and dispenser may immediately stop fueling, but may take safety measures and terminate the session by stopping communication.

[0469] Second, if a non-safety critical error occurs and fuel delivery is interrupted, preventing fuel delivery from being completed, the fuel delivery protocol can define a fallback mechanism, for example, by defining a non-communicative fuel delivery method.

[0470] Third, if a non-safety-critical error is detected in the mobility and the communication channel is still operational, the mobility may send a termination request message to the dispenser with "action" set to "stop" and "reason" set to an appropriate reason code.

[0471] Fourth, if a non-safety-critical error is detected by the dispenser and the communication channel is still operational, the dispenser may first immediately stop fueling and send a termination request message to the mobility with "Action" set to "Stop" and "Reason" set to an appropriate reason or reason code.

[0472] As described above, the communication method for hydrogen fueling can define error conditions related to the fueling protocol, provide detection criteria, and perform error handling steps including notification, termination steps, and fallback mechanisms when an error is detected by the detection criteria.

[0473] For successful refueling, communication must be designed to provide the expected behaviors according to the protocol. Refueling behavior must remain within acceptable limits within the refueling protocol. However, in reality, various abnormal events can occur. Some errors are minor and easily handled, while others are irrecoverable and may prevent refueling from continuing.

[0474] In this specification, 'error' may refer to an event that may interrupt the fueling process among the use cases (UC1 to UC9) or incidents that occur during the hydrogen fueling process.

[0475] In the error handling phase, conditions for non-safety critical errors, exemplary error conditions and their responses can be specified.

[0476] The purpose, brief description, prerequisites, and follow-up conditions of the use case (UC10) of the error handling step can be defined as illustrated in Table 28 below.

[0477] Description: Use Case Name: UC10: "Error Handling". Purpose: This use case handles situations where a non-safety-critical error occurs, similar to a normal termination, by terminating the fueling procedure or abruptly interrupting communication. Short Description: Non-safety-critical errors can occur at any time during fueling. In this case, the vehicle and dispenser first stop the use case and then move to the Terminate use case (UC9), which notifies both parties of the termination reason and completes the fueling procedure. If further communication is not possible, the communication channel is terminated without further notification. Precondition: A non-safety-critical error has occurred, and fueling can no longer be performed. Postcondition: The vehicle and dispenser are notified of the error and fueling is stopped.

[0478] Unsafe critical error conditions may include, for example, communication errors, system errors, and qualitative errors. Communication errors may include, for example, a disconnection in communication, incoming data that is unrecognizable due to encoding or syntactic errors, or incoming data that is in an unacceptable range. System errors may include, for example, a dispenser or mobility detecting its own critical system error. Qualitative errors may include, for example, a failure in communication performance to meet a required level, or a failure in data integrity or accuracy quality to meet a required level.

[0479] When a critical unsafe error occurs and further communication becomes impossible, the mobility and dispenser can immediately stop fueling, take safe steps, suspend communication, and terminate the session. Furthermore, when a critical unsafe error occurs and fueling is interrupted before the fueling procedure is complete, the fueling protocol can define, for example, a communication-less fueling method and a fallback mechanism.

[0480] Additionally, when an unsafe critical error is detected by the mobility and the communication channel is still operational, the mobility may send a termination request message to the dispenser with "action" set to "stop" and "reason" set to an appropriate reason code.

[0481] Additionally, when an unsafe critical error is detected by the dispenser and the communication channel is still operational, the dispenser may first immediately stop fueling and send a termination request message to the mobility with "action" set to "stop" and "reason" set to an appropriate reason code.

[0482] A fueling protocol may define protocol-specific error conditions and provide prescribed response procedures, including detection criteria, notification procedures, termination procedures, and fallback mechanisms.

[0483] Meanwhile, safety-critical issues may arise during fuel supply in a hydrogen fuel supply system, requiring urgent response.

[0484] Figure 32 is an example diagram showing the emergency handling procedure of the fuel supply framework of Figure 5 and the JSON message format of an emergency handling message that can be applied to its function block.

[0485] An eleventh use case (see UC11 in FIG. 5) for an emergency handling procedure that can be employed in the communication method for hydrogen fuel supply of the present embodiment may define safety-critical conditions requiring emergency response during hydrogen fuel supply and include a response process for preventing safety-critical accidents.

[0486] To ensure safe refueling, communication must behave as expected according to the protocol, and refueling operations must remain within the safe limits of the refueling protocol. However, problems can arise during refueling, potentially leading to a critical state in the refueling system—i.e., the hydrogen refueling system—that must be avoided at all costs. Therefore, emergency handling procedures can define safety-critical emergency conditions, possible responses to them, and provide critical cases to consider.

[0487] A fueling protocol can define emergency conditions associated with the protocol, provide detection criteria and performance requirements, and prescribe response steps to ensure that hazardous situations are not encountered.

[0488] Specifically, during the hydrogen fuel supply process, if a high pressure condition exceeding a preset reference value is detected by the mobility in a vehicle tank, etc., the mobility may transmit an emergency notification message including information requesting a fuel supply stop due to the high pressure (e.g., Emg: Stop (high pressure)) to the dispenser. The dispenser may transmit a response message including information indicating that it is urgently processing a fuel supply stop (e.g., Emg: Stopping) to the mobility in response to the emergency notification message.

[0489] Additionally, upon receiving a response message, either immediately or after a preset time has elapsed, the mobility may transmit an emergency notification message back to the dispenser. The dispenser may transmit a response message to the mobility containing information indicating that fuel supply has been urgently stopped (e.g., Emg: Stopped) based on the emergency notification message.

[0490] Meanwhile, if a hydrogen fuel leak is detected during the hydrogen fuel supply process, the dispenser may transmit an emergency notification message to the mobility, including information indicating that it is urgently handling the fuel supply stoppage due to the leak (e.g., Emg: Stopping (leaking)). The mobility may transmit a response message to the dispenser, including information indicating that it has normally received the emergency notification message (e.g., Emg: Confirmed).

[0491] Additionally, the dispenser may transmit an emergency notification message to the mobility, including information indicating that it has urgently processed a fuel supply interruption due to a leak (e.g., Emg: Stopped (leaking)). The mobility may transmit a response message to the dispenser, including information indicating that it has successfully received the emergency notification message (e.g., Emg: Confirmed).

[0492] The emergency notification messages in each of the aforementioned cases may be referred to as first to third emergency notification messages, respectively.

[0493] According to the above-described configuration, when a critical situation affecting safety is detected in the mobility or dispenser, the mobility or dispenser can immediately take necessary measures to prevent a dangerous situation or disaster from occurring, and, if possible, transmit an emergency notification message containing information about the situation to the other party and block communication.

[0494] When an emergency notification message is received, the mobility or dispenser can immediately respond according to the action indicated in the emergency notification message and terminate the communication without excessive delay. The emergency notification message includes a header (header, hdr) and a body (body) connected to the header, which includes a timestamp (ts), a session identifier (sid), and a message identifier (mid) indicating that it is an emergency notification (EmergencyNotif). The message may include values, information, or parameters regarding the class, type, and action of the emergency notification.

[0495] The aforementioned emergency notification message may be transmitted as a TLS or DTLS message, depending on the technology used for communication.

[0496] The purpose, brief description, prerequisites and postrequisites of Use Case 11 (UC11) for emergency handling procedures can be defined as illustrated in Table 29 below.

[0497] Use Case Description: Use Case Name: UC11: "Emergency Handling" Purpose: Defines safety-critical conditions that ensure emergency response and specifies response procedures to prevent safety-critical incidents. Short Description: To ensure safe refueling, communications must behave as expected by the protocol, and refueling operations must remain within the safe boundaries of the refueling protocol. However, problems can occur that could cause the refueling system to reach a critical state that must be avoided at all costs. This use case defines safety-critical emergency situations and possible responses, and provides best practices to consider. Precondition: A safety-critical event has occurred during refueling, requiring an urgent response. Postcondition: Avoid or minimize a safety-critical event and completely terminate the refueling session.

[0498] The fueling protocol can define emergency conditions according to the protocol and provide pre-defined response procedures to avoid entering a detrimental situation, including detection criteria, notification procedures, termination procedures, and fallback mechanisms. When a vehicle or dispenser detects a safety-critical situation, necessary actions can be immediately taken to prevent a catastrophic event. Furthermore, an emergency notification message can be transmitted with information about the event, if applicable, and communication can be closed. That is, when a vehicle or dispenser receives an emergency notification message, it can immediately respond with the actions indicated in the message and close communication without delay. The emergency notification message can be a TLS or DTLS message, depending on the communication technology used. To ensure message criticality and delivery efficiency, the fueling protocol can be configured to not allow modifications to the structure of the emergency notification message.

[0499] Element names included in an emergency notification message may include class, type, action, etc., and may be defined as exemplified in Table 30 below. Elements not exemplified in Table 30 below may be specified by a fuel supply protocol standard such as ISO 19885-3. For example, additional emergency reason codes and action codes may be individually specified for each protocol.

[0500] Element Name Type Meaning Class (class) unsignedByte Optional: The severity level of the emergency situation is from 1 to 5, with lower numbers indicating lower severity. Type (type) unsignedByte A predefined number of emergency reason codes. Action (action) unsignedByte Optional: A predefined action code that the recipient is required or recommended to perform.

[0501] FIG. 33 is a framework for functional blocks of a hydrogen fuel supply procedure to which a two-way communication method for hydrogen fuel supply according to another embodiment of the present invention can be applied. Referring to FIG. 33, the fuel supply framework, which is a framework for functional blocks of a hydrogen fuel supply procedure, includes a first functional block for discovery and pairing (S501) of a first use case (UC1), a second functional block for communication security (S502) of a second maintenance case (UC2), a third functional block for communication protocol negotiation (S503) of a third maintenance case (UC3), a fourth functional block for fuel supply protocol negotiation (S504) of a fourth use case (UC4), a fifth functional block for fuel supply parameter negotiation (S505) of a fifth use case (UC5), a sixth functional block for safety check-in (S506) of a sixth use case (UC6), a seventh functional block for monitoring and control (S507) of a seventh use case (UC7), and an eighth functional block for It may include an 8th function block for safe checkout (S508) of a use case (UC8), a 9th function block for termination (S509) of a 9th use case (UC9), a 10-1 function block for error detection (S510a) of a 10-1 use case (UC10-1), a 10-2 function block for use case stop (S510b) of a 10-2 use case (UC10-2), a 10th function block for error handling (S510) of a 10th use case (UC10), and an 11th function block for emergency handling (S511) of an 11th use case (UC11).

[0502] Except for the 10-1 function block for error detection (S510a) and the 10-2 function block for use case stop (S501b), the remaining function blocks are substantially the same as the corresponding function blocks of Fig. 5, and therefore, detailed descriptions thereof are omitted.

[0503] The 10-1 function block for error detection (S510a) and the 10-2 function block for use case stop (S501b) can transfer the result value or output signal to the 10th function block for error handling (S510) or the 11th function block for emergency handling (S511) according to the result of the corresponding function execution or judgment.

[0504] More specifically, the 10-1 function block can define a fallback mechanism that ensures backward compatibility among the mechanisms that are compatible between mobility and dispensers in the fueling protocol when a non-safety-critical error is detected in the monitoring and control phase and fueling is interrupted before fueling is completed, and can operate / function to resume fueling based on the fallback mechanism. In this case, the fallback mechanism can be, for example, a non-communication fueling method.

[0505] Meanwhile, the 10-1 function block can function / operate to return to the current stage of the fuel supply protocol to perform some or all of the steps for communication protocol negotiation (S503), fuel supply protocol negotiation (S504), and fuel supply parameter negotiation (S505) again if a non-safety critical error is found in the monitoring and control stage and fuel supply is interrupted before completion of the fuel supply.

[0506] At this time, the mobility and dispenser can reduce the information exchanged in the process of re-performing some or all of the communication protocol negotiation (S503), fuel supply protocol negotiation (S504), and fuel supply parameter negotiation (S505) using the interoperability information obtained in the discovery and pairing phase.

[0507] For example, if a communication state or fuel supply state is confirmed in which negotiation has already been completed and the selected protocol cannot be maintained, some or all of the communication protocol negotiation (S503), fuel supply protocol negotiation (S504), and fuel supply parameter negotiation (S505) may be performed again, excluding the previously selected protocol.

[0508] In addition, the 10-1 function block can function / operate to re-perform some or all of the communication protocol negotiation (S504), fuel supply protocol negotiation (S504), and fuel supply parameter negotiation (S505) with the counterparty corresponding to either mobility or dispenser when a change in the communication environment and a change in the fuel supply infrastructure are detected as non-critical errors to safety in the monitoring and control stage, and fuel supply is interrupted before fuel supply is completed.

[0509] Here, changes in the communication environment may include instances where the communication channel is disconnected. Furthermore, changes in the communication environment may include instances where received data is not recognized or instances where received data is within an unacceptable range. Furthermore, changes in the communication environment may include instances where the quality of communication performance does not meet a required level. Furthermore, changes in the communication environment may include instances where the integrity or precision of data exchanged through communication does not meet a required level.

[0510] And the change in the fuel supply infrastructure may include a case where the fuel supply parameters on the mobility side change or maintain a state based on the control parameters for fuel supply on the dispenser side, but the change or maintenance of the state of the fuel supply-related parameters on the mobility side does not meet the required level.

[0511] In this way, the 10-1 function block can detect various types of incidents or event-related events occurring in the mobility or dispenser while the third to ninth use cases are being executed. The detected incidents or events can be classified as errors when certain conditions are met. If the error is a non-safety-critical error, the error detection result is passed to the function block of the use case stop step or error handling step. If the error is a safety-critical error, the error detection result can be processed by the use case stop step and emergency handling step.

[0512] In this embodiment, the classification criteria for whether a detected error in Function Block 10-1 is classified as a non-safety critical error or a safety critical error are predefined in the fuel supply protocol. Depending on the stage at which an error is detected or the type of error classified, the detected error can be classified into a predefined class or type.

[0513] In this embodiment, after an error is detected, it is passed on to an error handling step and / or an emergency handling step, and each function block of these steps can classify an error that is not critical to safety into at least one of a communication error, a system error, and a qualitative error.

[0514] Next, the 10-2 function block can determine whether to stop the fueling process based on an error status according to received error information such as an error classification result from the 10-1 function block. If it is determined not to stop the fueling process and to continue the fueling process based on updated interoperability or compatibility information and by a fallback fueling protocol, at least one processor of the fueling system can continue the fueling process by performing any one of the 3rd to 8th use cases again as a result of the error handling step.

[0515] In this way, the 10-2 function block can be configured to determine whether to stop the communication process or the hydrogen fuel supply process based on the error detection result of the 10-1 function block, and to stop the currently running use case accordingly.

[0516] Meanwhile, the 10-2 function block may be configured to classify an error as either a safety-critical error or a non-safety-critical error based on the error detection result of the 10-1 function block. If the error is classified as a non-safety-critical error, the 10-2 function block may classify the error as either a communication error, a system error, or a qualitative error. If the error is classified as a safety-critical error, the 10-2 function block may transmit the detected error information and / or the classified error information to the 11th function block, which performs subsequent processing such as emergency processing (S511). A safety-critical error may be treated as an emergency.

[0517] Additionally, the 10-2 function block can determine the severity of an error based on the available communication or fuel supply process UCDC level in relation to the detected error. Furthermore, it can determine whether to stop fuel supply based on the UCDC level. In this case, the process of determining the severity of an error and / or whether to stop fuel supply based on the UCDC level can be applied when the error is a qualitative error.

[0518] Criteria for determining whether an error is critical to safety include whether an accident or incident that could occur before, during, or after hydrogen refueling could cause damage to hydrogen charging station facilities and / or personnel, or could result in fire, explosion, or leakage. In the case of a safety-critical error, communication and fueling may be suspended and / or terminated. Even in the case of a safety-critical error, fueling may continue if communication is secured, fueling is possible, or fueling must continue for reasons such as evacuating a hazardous area or transporting a patient. In the case of a non-safety-critical error, communication or fueling may be suspended based on the severity of the error, available communication environment, available fueling protocol, UCDC level, and the need for communication or fueling.

[0519] In the above embodiments, the process of continuous monitoring of interoperability, updating of interoperability information accordingly, and / or updating of a combination of communication protocols or fuel supply protocols has been disclosed with a focus on embodiments in which either the mobility or the dispenser performs the process, but the detailed processes of these processes may be performed through mutual cooperation between the mobility and the dispenser. In this embodiment, some of the processes of continuous monitoring of interoperability, updating of interoperability information accordingly, and / or updating of a combination of communication and fuel supply protocols may be proactively performed by the mobility, and other parts may be proactively performed by the dispenser.

[0520] Additionally, the detection of an error may be performed by either the mobility or the dispenser, and the entity that detected the error may transmit a message to the other party including the detection of the error, the detected error, the suspension of communication and fuel supply based on the error, or a reason code corresponding to the reason for the suspension.

[0521] According to the present embodiment, a communication method for hydrogen fueling performed by hydrogen mobility may be configured to include a step (S510a) of detecting an error that occurs during a process (S503 to S506) for preparing hydrogen fueling between a dispenser that supplies hydrogen to mobility or a process (S507) in which the dispenser supplies hydrogen to mobility, and a step (S510b) of stopping a use case for a communication process or a hydrogen fueling process based on the detected error, and an error handling step (SS510) or an emergency handling step (S511) that is a predefined subsequent processing processor to operate based on the detected error.

[0522] FIG. 34 is a conceptual block diagram of a computing system applicable to a hydrogen fuel supply communication device according to another embodiment of the present invention. FIG. 35 is a block diagram illustrating a software module of a hydrogen fuel supply communication device that may be additionally employed in the computing system of FIG. 34.

[0523] Referring to FIG. 34, a computing system (3400) includes a communication device, a communication control device, a communication structure, and / or an electronic control device for hydrogen charging, and may be mounted on a hydrogen mobility, dispenser, and / or charging station. Although omitted from the drawings in the above-described embodiments, the computing system may be configured such that a processor and a memory are electronically connected to each component, and the operation of each component is controlled or managed by the processor. That is, at least a portion of the process of the communication method for hydrogen fuel supply according to the present embodiment may be executed by the computing system (3400).

[0524] A computing system (3400) may include at least one processor (processor) 3410 and a memory (memory) 3420 that stores instructions that direct the at least one processor (3410) to perform at least one step. The at least one step may be performed by the at least one processor (3410) loading and executing instructions from the memory (3420).

[0525] In addition, the computing system (3400) may further include a communication interface that forms a wired or wireless channel, and a transmission / reception device (3430) that transmits and receives signals or information through a communication network to which the communication interface is connected. Furthermore, the computing system (3400) may further include an input interface (3440), an output interface (3450), a storage device (3460), etc. In addition, each component included in the computing system (3400) may be connected by a bus (3470) to communicate with each other.

[0526] The processor (3410) may mean a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which the method according to the present embodiment is performed.

[0527] Each of the memory (3420) and the storage device (3460) may be configured with at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory (3420) may be configured with at least one of a read-only memory (ROM) and a random access memory (RAM).

[0528] In addition, referring to FIG. 35, the computing system (3400) may include additional functional blocks (3411 to 3418 of FIG. 35) in addition to the functional blocks (UC1 to UC11) previously described with reference to FIG. 5 or FIG. 31. These functional blocks (3411 to 3418) may be mounted on the computing system (3400) including a hydrogen fuel supply communication device or a hydrogen fuel supply control device.

[0529] The additional function blocks (3411 to 3418) described above may include a first function block (3411) for version negotiation, a second function block (3412) for session allocation, a third function block (3413) for service negotiation, a fourth function block (3414) for payment negotiation, a fifth function block (3415) for authentication, a sixth function block (3416) for fuel supply parameter exchange, a seventh function block (3417) for fuel supply, and an eighth function block (3418) for stop / pause.

[0530] The first function block (3411) can check and compare the versions of communication protocols available for all fueling protocols during handshake. Furthermore, the first function block (3411) can check the TLS version, etc.

[0531] The second function block (3412) can assign an IP address, an IPv6 address, a session identifier, etc. by a vehicle or dispenser.

[0532] The third function block (3413) can negotiate services applied to hydrogen electric vehicles based on price, user convenience, etc. when there are differences in service items such as charging fees by region, time zone, or service provider in hydrogen fuel supply.

[0533] The fourth function block (3414) can determine the payment method for hydrogen charging and process the payment process.

[0534] The fifth function block (3415) can process at least one of user authentication, vehicle authentication, dispenser authentication, and hydrogen charging station authentication. The fifth function block (3415) can correspond to at least a portion of the function blocks of the discovery and pairing use case (UC1).

[0535] The sixth function block (3416) may correspond to at least a part of the function blocks of the fuel supply parameter negotiation use case (UC5).

[0536] The seventh function block (3417) is a functional unit for initiating, monitoring, and controlling fuel supply, and may correspond to at least a portion of the monitoring and control use case (UC7). In addition, the seventh function block (3417) may correspond to at least a portion of a combination of the safe check-in use case (UC6), the monitoring and control use case (UC7), the safe check-out use case (UC8), and the termination use case (UC9).

[0537] The eighth function block (3418) is for stopping a use case or stopping or pausing the fuel supply and / or communication function during normal fuel supply or in case of error handling or emergency handling due to error detection, and can correspond to at least a part of a combination of an error handling use case (UC10) and an emergency handling use case (UC11).

[0538] In addition, the computing system (3400) described above can be implemented as various types of computing devices mounted on a vehicle or dispenser. The types of computing devices can include a desktop computer, a laptop computer, a notebook, a smart phone, a tablet PC, a mobile phone, a smart watch, a smart glass, an e-book reader, a portable multimedia player (PMP), a portable game console, a navigation device, a digital camera, a digital multimedia broadcasting (DMB) player, a digital audio recorder, a digital audio player, a digital video recorder, a digital video player, a PDA (Personal Digital Assistant), etc. capable of communication.

[0539] Meanwhile, while most of the aforementioned embodiments have focused on first transmitting the vehicle's communication protocol or parameters from the vehicle to the dispenser, the present invention is not limited to such a configuration and can be configured to first transmit the dispenser's communication protocol or parameters from the dispenser to the vehicle. In this case, it is self-evident that the embodiments have substantially the same features, except that the transmitter becomes the receiver and the receiver becomes the sender.

[0540] The operations of the method according to an embodiment of the present invention can be implemented as a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes any type of recording device that stores information readable by a computer system. Furthermore, a computer-readable recording medium can be distributed across network-connected computer systems, allowing the computer-readable program or code to be stored and executed in a distributed manner.

[0541] Additionally, the computer-readable recording medium may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. The program instructions may include not only machine language codes produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc.

[0542] While some aspects of the present invention have been described in the context of a device, they may also represent a description of a corresponding method, wherein a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method may also be described as a corresponding block or item or a feature of a corresponding device. Some or all of the method steps may be performed by (or using) a hardware device, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one or more of the most important method steps may be performed by such a device.

[0543] In embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. In embodiments, the field-programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by some hardware device.

[0544] Although the present invention has been described above with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various modifications and changes may be made to the present invention without departing from the spirit and scope of the present invention as set forth in the claims below.

Claims

1. A two-way communication method for hydrogen fueling performed by hydrogen mobility, A step of negotiating a communication protocol with a dispenser for refueling hydrogen with hydrogen mobility, based on information related to interoperability or compatibility that has been previously confirmed, and for a process in which the dispenser refuels hydrogen with the mobility; A step of negotiating fueling protocols for supplying hydrogen fuel to the above dispenser; A step of negotiating fueling parameters with the dispenser based on a fueling protocol negotiated with the dispenser; and A communication method for hydrogen fueling, comprising: a step of monitoring the start of the hydrogen fueling and the status of the hydrogen fueling through a fueling loop request message and a fueling loop response message based on the negotiated fueling protocol and the negotiated fueling parameters.

2. In claim 1, A hydrogen fuel supply two-way communication method, wherein, in the above monitoring step, the fuel supply loop request message includes a field for a current operation and a field indicating a reason for the operation, and wherein the hydrogen fuel supply is started according to preset information of the field for the operation.

3. In claim 2, A hydrogen fuel supply two-way communication method, wherein in the above monitoring step, the fuel supply loop response message includes fields indicating the status, reason, and result of the current operation, wherein the field indicating the status includes information indicating that the current status is fueling, and the field indicating the result includes information indicating that the monitoring result or control state is normal.

4. In claim 3, A method for two-way communication of hydrogen fueling, wherein the monitoring step comprises transmitting a message including information about a fueling loop of the hydrogen mobility itself to the dispenser, and receiving a message including information about a fueling loop of the dispenser itself corresponding to the fueling loop of the mobility from the dispenser.

5. In claim 3, A hydrogen fuel supply two-way communication method, wherein the monitoring step comprises the step of transmitting a fuel supply control request message including information for slowing down the fuel supply or reducing the unit fuel supply amount to the dispenser, and receiving a response message including information indicating a decrease in the fuel supply status or a decrease in the speed from the dispenser.

6. In claim 3, A hydrogen fuel supply two-way communication method, wherein the monitoring step comprises the steps of transmitting a fuel supply control request message requesting the stopping of fuel supply to the dispenser, and receiving a fuel supply status response message including information on stopping or stopping fuel supply from the dispenser.

7. In claim 3, A method for two-way communication of hydrogen fueling, wherein the monitoring step comprises transmitting information or parameters about the current tank temperature and current tank pressure of the hydrogen mobility to the dispenser, and receiving parameters related to at least one of fueling start, stop, ramping up, ramping down, and current injection pressure from the dispenser.

8. In claim 3, A method for two-way hydrogen fuel supply communication, wherein the monitoring step comprises transmitting information or parameters regarding start, pause, resume, or termination of fuel supply to the dispenser.

9. In claim 1, It further includes a step of detecting an error occurring during the communication process of preparing the hydrogen fuel supply or the process of the dispenser performing the hydrogen fuel supply to the hydrogen mobility. A hydrogen fuel supply two-way communication method, wherein the above detected error is classified as a safety-critical error or a non-safety-critical error.

10. In claim 9, A step of determining whether to stop the communication process or the hydrogen fuel supply process based on the detected error; and A step of transmitting a message to the dispenser including whether to stop the communication process or the process of performing the hydrogen fuel supply; A two-way communication method for hydrogen fuel supply, further comprising:

11. In claim 9, If the above detected error is not a safety critical error, further comprising a step of performing an error handling procedure, A method for two-way communication for hydrogen fuel supply, wherein the step of performing the above error handling procedure includes the step of classifying the detected error into at least one of a communication error, a system error, and a qualitative error.

12. In claim 11, A hydrogen fuel supply bidirectional communication method, further comprising a step of determining whether to replace the first fuel supply protocol of the communication process or the process of performing the hydrogen fuel supply with a fallbacked second fuel supply protocol if the detected error is not a safety-critical error.

13. In claim 9, A hydrogen fuel supply two-way communication method further comprising the step of performing an emergency handling procedure if the above-detected error is a safety-critical error.

14. A two-way communication method for hydrogen fueling, performed by a dispenser that supplies hydrogen fueling through hydrogen mobility or a hydrogen charging station equipped with the dispenser, A step of negotiating a communication protocol for a process of fueling hydrogen with the hydrogen mobility and the mobility based on information related to interoperability or compatibility confirmed in advance; A step of negotiating fueling protocols for the above hydrogen mobility and hydrogen fuel supply; A step of negotiating fueling parameters with the hydrogen mobility based on the fueling protocol negotiated with the hydrogen mobility; and A communication method for hydrogen fueling, comprising: a step of monitoring the start of the hydrogen fueling and the status of the hydrogen fueling through a fueling loop request message and a fueling loop response message based on the negotiated fueling protocol and the negotiated fueling parameters.

15. In claim 14, A hydrogen fuel supply two-way communication method, wherein in the above monitoring step, the fuel supply loop request message includes a field for a current operation and optionally includes a field indicating a reason for the operation, wherein the hydrogen fuel supply is started according to preset information in the field for the operation.

16. In claim 15, A hydrogen fuel supply two-way communication method, wherein in the above monitoring step, the fuel supply loop response message includes fields indicating the status, reason, and result of the current operation, wherein the field indicating the status includes information indicating that the current status is fueling, and the field indicating the result includes information indicating that the monitoring result or control state is normal.

17. In claim 14, A hydrogen fuel supply two-way communication method further comprising a step of controlling a parameter including a pressure rise rate or an average pressure rise rate based on information from the hydrogen mobility to control the fuel supply speed in the hydrogen fuel supply.

18. In claim 14, It further includes a step of detecting an error occurring during the communication process of preparing the hydrogen fuel supply or the process of the dispenser performing the hydrogen fuel supply to the hydrogen mobility. A hydrogen fuel supply two-way communication method, wherein the above detected error is classified as a safety-critical error or a non-safety-critical error.

19. In claim 18, A hydrogen fuel supply two-way communication method, further comprising the step of receiving a message including information or parameters for determining whether to stop the communication process or the hydrogen fuel supply process based on the error detected from the hydrogen mobility.

20. In claim 18, If the above detected error is not a safety critical error, further comprising a step of performing an error handling procedure, A method for two-way communication for hydrogen fuel supply, wherein the step of performing the above error handling procedure includes the step of classifying the detected error into at least one of a communication error, a system error, and a qualitative error.

21. In claim 20, A hydrogen fuel supply bidirectional communication method, further comprising the step of determining whether to replace the first fuel supply protocol of the communication process or the process of performing the hydrogen fuel supply with a fallbacked second fuel supply protocol if the detected error is not a safety-critical error.

22. In claim 20, A hydrogen fuel supply two-way communication method further comprising the step of performing an emergency handling procedure if the above-detected error is a safety-critical error.

23. A hydrogen fuel supply two-way communication device deployed in hydrogen mobility, a memory storing at least one command; and comprising a processor for executing at least one instruction; The processor, by means of at least one instruction, A step of negotiating a communication protocol with a dispenser for refueling hydrogen with hydrogen mobility, based on information related to interoperability or compatibility that has been previously confirmed, and for a process in which the dispenser refuels hydrogen with the mobility; A step of negotiating fueling protocols for supplying hydrogen fuel to the above dispenser; A step of negotiating fueling parameters with the dispenser based on a fueling protocol negotiated with the dispenser; and A step of monitoring the start of the hydrogen fuel supply and the status of the hydrogen fuel supply based on the negotiated fuel supply protocol and the negotiated fuel supply parameters through a fueling loop request message and a fueling loop response message; configured to perform; Hydrogen fuel supply two-way communication device.

24. In claim 23, The above fuel supply loop request message includes a field for the current operation and a field indicating the reason for the operation, wherein the hydrogen fuel supply is started according to the preset information in the field for the operation, The above fuel supply loop response message includes fields indicating the status, reason and result of the current operation, wherein the field indicating the status includes information indicating that the current state is fuel supplying, and the field indicating the result includes information indicating that the monitoring result or control state is normal. Hydrogen fuel supply two-way communication device.

25. In claim 24, The above processor, A step for detecting an error occurring during a communication process for preparing the hydrogen fuel supply or during a process in which the dispenser performs hydrogen fuel supply to the hydrogen mobility; A step of determining whether to stop the communication process or the hydrogen fuel supply process based on the detected error; A step of performing an error handling procedure when the above detected error is not a safety critical error; and If the above detected error is a safety critical error, a step of performing emergency handling procedures is further performed, In the step of detecting the above error or the step of determining, the detected error is classified as a safety-critical error or a non-safety-critical error, The step of performing the above error handling procedure is, when the detected error is not a safety critical error, classifying the detected error into at least one of a communication error, a system error, and a qualitative error, A hydrogen fuel supply two-way communication device, wherein the step of performing the above error handling procedure further includes the step of determining whether to replace the first fuel supply protocol of the communication process or the process of performing the hydrogen fuel supply with a fallbacked second fuel supply protocol when the detected error is a non-safety critical error.

Images