ES2957168T3 - Procedimiento para identificar y verificar un software de control de un vehículo ferroviario - Google Patents

Procedimiento para identificar y verificar un software de control de un vehículo ferroviario Download PDF

Info

Publication number
ES2957168T3
ES2957168T3 ES21701903T ES21701903T ES2957168T3 ES 2957168 T3 ES2957168 T3 ES 2957168T3 ES 21701903 T ES21701903 T ES 21701903T ES 21701903 T ES21701903 T ES 21701903T ES 2957168 T3 ES2957168 T3 ES 2957168T3
Authority
ES
Spain
Prior art keywords
fkt
control software
country
function
checksum
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES21701903T
Other languages
English (en)
Inventor
Matthias Alexander Weber
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Mobility GmbH
Original Assignee
Siemens Mobility GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Mobility GmbH filed Critical Siemens Mobility GmbH
Application granted granted Critical
Publication of ES2957168T3 publication Critical patent/ES2957168T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L15/00—Indicators provided on the vehicle or train for signalling purposes
    • B61L15/0081—On-board diagnosis or maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L15/00—Indicators provided on the vehicle or train for signalling purposes
    • B61L15/0018—Communication with or on the vehicle or train
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Mechanical Engineering (AREA)
  • Quality & Reliability (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)

Abstract

La invención se refiere a un método para identificar y verificar el software de control de un vehículo ferroviario. En dicho método, el software de control está formado por funciones (FKT_1,...), cumpliendo cada función (FKT_1,...) una tarea asociada. Como colectivo interconectado, las funciones (FKT_1,...) forman la estructura (STR) del programa de control. Para cada función (FKT_1,...) se genera una suma de comprobación dependiente de la función (HFKT_1,...). Para la estructura (STR) se genera una suma de comprobación dependiente de la estructura (HSTR). A partir de las sumas de control dependientes de la función (HFKT_1,...) y de la suma de control dependiente de la estructura (HSTR) se genera una suma de control total (HGES) para el software de control. Esta suma de control total (HGES) identifica y verifica el software de control para la homologación en un país (UE, ZLL). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento para identificar y verificar un software de control de un vehículo ferroviario
La invención se refiere a un procedimiento para identificar y verificar un software de control de un vehículo ferroviario. Los vehículos ferroviarios diseñados para un uso transfronterizo disponen de un software de control cuyos elementos funcionales, algunos de ellos estructurados en bloques, están indisolublemente unidos entre sí.
Un software de control cumple con los requisitos específicos de cada país y está aprobado y verificado para la red viaria de un país.
A través del software de control se calcula una suma de comprobación. A partir de la suma de comprobación se realiza la aprobación específica del país y se garantiza la verificación del software de control para ese país.
El documento US2016266890 divulga un procedimiento para identificar y verificar el software de control para un dispositivo móvil. Se calcula una suma de comprobación a través del software de control para identificar y verificar el software de control.
Las diferentes especificaciones específicas de cada país dan como resultado diferentes versiones de un software de control considerado para cada país.
Los fabricantes de software de control desean poder utilizar un software de control unitario y aprobado para un gran número de países.
Partiendo de esto, a continuación se describen a modo de ejemplo los inconvenientes del proceso de aprobación en Europa:
Existe el riesgo de que un software de control que ya ha sido aprobado en un primer grupo de países de Europa deba modificarse debido a una objeción de otro país.
Si se planea un uso en varios países, el software de control ahora modificado pierde las aprobaciones que ya se hayan concedido en los países del primer grupo de países de Europa y debe ser aprobado nuevamente en estos países. Además, existe el riesgo de que se requieran distinciones específicas de cada país para determinadas funciones del software de control, lo que significa que en toda Europa habrá que resolver enfoques contradictorios para el software de control.
Para minimizar o eliminar estos inconvenientes es conocido prever en el vehículo ferroviario un software de control específico para cada país. Al cruzar una frontera, se selecciona un software de control específico del país asociado y se carga en una unidad de control del vehículo ferroviario.
Sin embargo, este enfoque tiene los siguientes inconvenientes:
- deberá estar previsto en el vehículo un sistema de almacenamiento redundante para diferentes software de control o para diferentes programas de control y parámetros,
- los programas y parámetros deben recargarse en las fronteras nacionales, tardando la recarga mucho tiempo debido al tamaño del programa,
- deben establecerse si la recarga debe realizarse con el vehículo ferroviario parado o en funcionamiento durante el cruce de fronteras,
- deben aclararse cuestiones relativas a la responsabilidad en la recarga (por ejemplo, si la recarga puede o debe ser realizada por el conductor del vehículo ferroviario o no),
- en caso de que una autoridad deniegue la aprobación, es posible que sea necesario mantener disponibles los programas y parámetros antiguos aprobados para poder cargarlos,
- durante el mantenimiento se debe garantizar que en los sistemas de almacenamiento redundantes estén instalados los conjuntos de software de control correctos en cada caso,
- normalmente en un vehículo ferroviario se instalan varias unidades de control, de modo que el número de programas se multiplica y el resultado son mayores costes unitarios;
- en última instancia, hay que invertir más esfuerzo en el desarrollo, gestión y mantenimiento de los programas. En resumen, la viabilidad de este enfoque es muy limitada.
Por lo tanto, el objetivo de la presente invención es especificar un software de control para un vehículo ferroviario de tal manera que sea posible una aprobación más sencilla y al mismo tiempo al menos se reduzcan o se eviten por completo los inconvenientes mencionados anteriormente.
Este objetivo se consigue mediante las características de la reivindicación 1. Perfeccionamientos ventajosos se especifican en las respectivas reivindicaciones dependientes.
En el procedimiento según la invención para identificar y comprobar el software de control de un vehículo ferroviario, el software de control se describe mediante funciones que, vistas en su conjunto, están interconectadas estructuralmente entre sí.
Una función cumple una tarea que se le ha asignado, mientras que la totalidad la interconexión de funciones se denomina estructura del software de control.
Para cada función se crea una suma de comprobación dependiente de la función y los cambios en una función se indican mediante un cambio en la suma de comprobación respectiva.
Para la estructura se crea una suma de comprobación dependiente de la estructura y un cambio en la estructura se indica mediante un cambio en la suma de comprobación estructural.
A partir de las sumas de comprobación dependientes de la función de las funciones utilizadas y a partir de la suma de comprobación dependiente de la estructura de la estructura se forma una suma de comprobación global que crea una huella digital unívoca de un software de control concreto y se utiliza para la verificación.
La aprobación en un país se realiza sobre la base de la suma de comprobación global.
Se realiza un cambio específico del país en funciones seleccionadas y/o en la estructura. Esto modifica la suma de comprobación dependiente de la función y/o la suma de comprobación dependiente de la estructura y, en última instancia, la suma de comprobación global.
Por lo tanto, el cambio específico del país provoca un cambio en la suma de comprobación global, lo que indica este cambio.
Cualquier aprobación posterior necesaria se realiza sobre la base de la suma de comprobación global.
Una suma de comprobación global sin cambios indica que el software de control no ha cambiado y no es necesario comprobarlo ni aprobarlo nuevamente para un país específico.
Por consiguiente, una suma de comprobación global modificada indica un software de control modificado, que debe comprobarse y aprobarse nuevamente en cada país.
Como parte de un informe detallado que se puede realizar en el software de control, sumas de comprobación de función sin cambios indican funciones sin cambios cuya influencia en el software de control no es necesario volver a comprobar.
Por lo tanto, las sumas de comprobación de funciones modificadas indican funciones modificadas, cuya influencia en el software de control debe comprobarse nuevamente.
En un perfeccionamiento ventajoso, si las funciones y si la estructura del software de control permanecen sin cambios, se forma una suma de comprobación global que indica un software de control sin cambios.
En el caso de un cambio específico del país en el software de control, se forma una función específica del país a partir de una función sin cambios seleccionada, modificando la función. Al formar la función específica del país se forma una suma de comprobación global específica del país, que difiere de la suma de comprobación global del software de control sin cambios.
En el caso de un cambio específico del país en la estructura del software de control, se forma una estructura específica del país. Al formar la estructura específica del país se forma una suma de comprobación global específica del país, que difiere de la suma de comprobación global del software de control sin cambios.
En un perfeccionamiento ventajoso, en el software de control se activa y opera o bien la función específica del país o bien la función sin cambios mediante un identificador de país.
Si se activa la función específica del país y la estructura del software de control permanece sin cambios, se muestra la suma de comprobación global específica del país del software de control para su verificación.
Si se activa la función sin cambios y la estructura del software de control permanece sin cambios, se muestra la suma de comprobación global del software de control sin cambios para su verificación.
En un perfeccionamiento ventajoso, el identificador de país se selecciona en función de la red viaria en la que se encuentra el vehículo ferroviario o en la que circula o entra el vehículo ferroviario.
En un perfeccionamiento ventajoso, para fines de control se muestra al conductor del vehículo ferroviario la identificación de país y/o un número de versión correspondiente del software de control, que se basa en la suma de comprobación global del software de control.
En un perfeccionamiento ventajoso, una primera función proporciona resultados tanto a la función sin cambios como a la función específica del país como funciones descendentes. Las dos funciones descendentes determinan resultados respectivos. Sin embargo, utilizando el identificador de país, que actúa sobre un bloque de selección, solo uno de los resultados se transmite a otra función.
En un perfeccionamiento ventajoso, se detectan puntos de intersección al determinar la estructura en el recorrido de las señales del software de control. Las conexiones detectadas a través de los puntos de intersección se sustituyen para calcular la suma de comprobación de la estructura.
Mediante la presente invención se identifica unívocamente el estado de aprobación del software de control de un vehículo ferroviario y así se verifica una aprobación.
En resumen, se crea una suma de comprobación global de los códigos fuente asociados para cada software de control dependiente de la red viaria o del país y se le proporciona un número de versión. Esto crea una huella digital significativa para el software de control de cada país.
Dependiendo de la red viaria nacional en la que opere el vehículo ferroviario, se activa el software de control asociado y se muestra al conductor del vehículo ferroviario un número de versión correspondiente del software de control para fines de control.
Si se realizan cambios en el software de control de una red viaria de un país, por ejemplo debido a requisitos de una autoridad de aprobación, la parte del software de control específica de esta red viaria se complementa o modifica. El código o código fuente superpuesto afectado por los cambios se copia y modifica.
Mediante un procedimiento adecuado para la creación de la huella digital se puede demostrar, para todas las partes del software de control específicas de la red que no han cambiado, mediante las respectivas sumas de comprobación, que estas permanecen sin cambios, lo que significa que ya no es necesario una nueva aprobación de estas partes del software por parte de las autoridades que ya habían aprobado estas partes del software.
Mediante la presente invención es posible
- que se reduzcan los costes de aprobación y los riesgos,
- que se reduzca el llamado "time to market", y
- que las exigencias de los clientes específicas de la red se puedan implementar con poco esfuerzo desde el punto de vista de la aprobación.
La presente invención tiene una ventaja particular si se puede mantener la estructura de las funciones en el caso de un cambio específico del país en el software de control.
Entonces es posible cambiar fácilmente entre funciones específicas de cada país dependiendo de las redes viarias o de los países. El propio software de control contiene las funciones respectivas. Al cruzar la frontera se evita así tener que cargar software de control específico del país; al cruzar la frontera simplemente se produce un cambio de función específico del país.
Al cambiar de una función seleccionada a una función específica del país, se logra una aprobación en un país de destino y se muestra a través de la suma de comprobación global asociada.
Al mismo tiempo se mantiene una aprobación ya concedida en otros países, ya que para estos países la función seleccionada permanece sin cambios, es decir, no se modifican ni las sumas de comprobación de las funciones implicadas ni la suma de comprobación de la estructura ni la suma de comprobación global.
La invención se explica a continuación con más detalle mediante un dibujo a modo de ejemplo. A este respecto muestra:
FIG 1 una representación básica de una posición inicial para el procedimiento según la invención,
FIG 2 con referencia a la figura 1, una situación para consideraciones posteriores de la invención,
FIG 3 con referencia a las figuras anteriores, detalles del procedimiento según la invención,
FIG 4 con referencia a la figura 3, una configuración ventajosa del procedimiento según la invención, y FIG 5 con referencia a la figura 4, un perfeccionamiento ventajoso del procedimiento según la invención.
La figura 1 muestra una representación básica de una posición inicial para el procedimiento según la invención para una aprobación prevista del software de control de un vehículo ferroviario.
El procedimiento según la invención se basa en que el software de control está formado, como programa, por una serie de funciones FKT_1, FKT_2, FKT_3 interconectadas estructuralmente.
A cada función FKT_1, FKT_2, FKT_3 se le asigna una tarea que debe realizar.
Sobre cada función FKT_1, FKT_2, FKT_3 se forma en cada caso una suma de comprobación como el denominado "hash", de modo que
- una primera función FKT_1 tiene una primera suma de comprobación HFKT_1,
- una segunda función FKT_2 tiene una segunda suma de comprobación HFKT_2, y
- una tercera función FKT_3 tiene una tercera suma de comprobación HFKT_3.
Las funciones FKT_1, FKT_2, FKT_3 del software de control, representado aquí de manera muy sencilla, están interconectadas estructuralmente.
La interconexión de las funciones FKT_1, FKT_2, FKT_3 forma una estructura STR. A través de esta estructura STR también se forma una suma de comprobación HSTR, denominada hash.
En la estructura STR que se muestra aquí, la primera función FKT_1 está vinculada con la tercera función FKT_3 o bien directamente o bien a través de la segunda función FKT_2.
A partir de las sumas de comprobación de las funciones HFKT_1 a HFKT_3 y a partir de la suma de comprobación de la estructura HSTR se forma una suma de comprobación global HGES, que describe unívocamente el software de control y, por lo tanto, puede considerarse como su huella digital.
El software de control se aprueba sobre la base de la suma de comprobación global HGES.
La figura 2 muestra, con referencia a la figura 1, una situación para consideraciones posteriores de la invención. En este caso se parte del supuesto de que la segunda función FKT_2 no está aprobada en el país seleccionado, en lo sucesivo denominado país de destino ZLL.
Por ejemplo, en el marco de la aprobación en el país de destino se necesita una funcionalidad de la segunda función FKT_2 adaptada al país de destino ZLL. Esta situación se muestra con un símbolo de rayo en el caso de la segunda función F<k>T_2.
La figura 3 muestra detalles del procedimiento según la invención con referencia a las figuras anteriores.
Se supone que se ha concedido la primera aprobación para Europa para el software de control.
Esta aprobación, en lo sucesivo denominada aprobación UE, se basa en una suma de comprobación global HGES_EU.
Sin embargo, el software de control no está aprobado en el país de destino ZLL, por lo que, con referencia a la figura 2, es necesario cambiar la segunda función FKT_2 allí representada.
Por tanto, la suma de comprobación global HGES_EU se basa en:
- la primera suma de comprobación HFKT_1 de la primera función FKT_1
- una segunda suma de comprobación HFKT_2 EU de una segunda función FKT_2 EU,
- la tercera suma de comprobación HFKT_3 de la tercera función FKT_3, y en
- la suma de comprobación HSTR de la estructura STR.
Con respecto a las figuras anteriores, la segunda función FKT_2 EU mostrada aquí corresponde a la segunda función FKT_2 descrita en la figura 1 y la figura 2.
La segunda suma de comprobación HFKT_2 EU corresponde por lo tanto a la segunda suma de comprobación HFKT_2 descrita en la figura 1 y la figura 2.
Con respecto a las figuras anteriores, la suma de comprobación global HGES_EU corresponde a la aprobación UE de la suma de comprobación global HGES descrita en la figura 1 y la figura 2.
La aprobación para el país de destino ZLL, en lo sucesivo denominada aprobación ZLL, se basa en una suma de comprobación global HGES_ZLL.
La suma de comprobación global HGES_ZLL se basa en:
- la primera suma de comprobación HFKT_1 de la primera función FKT_1
- una segunda suma de comprobación HFKT_2 ZLL de una segunda función FKT_2 ZLL,
- la tercera suma de comprobación HFKT_3 de la tercera función FKT_3, y se basa en
- la suma de comprobación HSTR de la estructura STR.
Para el país de destino ZLL, la estructura STR de las funciones FKT_1, FKT_2 ZLL, FKT_3 implicadas no cambia con respecto a las figuras anteriores.
Tan solo la segunda función FKT_2 ZLL se adapta a las necesidades específicas del país, del país de destino ZLL, o a las necesidades de la red viaria asociada.
Por consiguiente, la segunda función FKT_2 ZLL tiene una segunda suma de comprobación HFKT_2 ZLL asignada a la misma.
Como se describió anteriormente, se forman "hashes" o sumas de comprobación para las funciones individuales: - para la primera función FKT_1, la primera suma de comprobación HFKT_1,
- para la segunda función FKT_2 ZLL adaptada al país de destino ZLL, la segunda suma de comprobación HFKT_2 ZLL y
- para la tercera función FKT_3, la tercera suma de comprobación HFKT_3.
Cabe señalar que la estructura STR es la misma para la aprobación en el país de destino y para la aprobación UE: Para la aprobación UE, la primera función FKT_1 está vinculada con la tercera función FKT_3 directamente o a través de la segunda función FKT_2 EU.
Para la aprobación en el país de destino, la primera función FKT_1 está vinculada con la tercera función FKT_3 directamente o a través de la segunda función FKT_2 ZLL.
Esto significa que la suma de comprobación HSTR formada mediante la estructura STR es idéntica para los países europeos y para el país de destino.
En el marco de la aprobación UE, que es válida, por ejemplo, para todos los países europeos, pero no para el país de destino ZLL, la tercera función FKT_3 utiliza, por tanto, en caso necesario, los resultados de la segunda función FKT_2 EU, mientras que, en el marco de la aprobación en el país de destino, la tercera función FKT_3 utiliza los resultados de la segunda función FKT_2 ZLL.
Para la aprobación UE se utilizan las sumas de comprobación HFKT_1, HFKT_2 EU, HFKT_3 y HSTR. A partir de estas sumas de comprobación se forma la suma de comprobación global HGES_EU.
Para la aprobación en el país de destino se utilizan las sumas de comprobación HFKT_1, HFKT_2 ZLL, HFKT_3 y HSTR. A partir de estas sumas de comprobación se forma una suma de comprobación global HGES_ZLL.
Con esto se demuestra de forma impresionante una ventaja significativa de la presente invención:
Manteniendo la misma estructura STR, al diseñar el software de control es posible cambiar entre funciones específicas del país dependiendo de las redes viarias o de los países; en este caso, según el país, entre las segundas funciones FKT_2 ZLL y FKT_2 EU.
El propio software de control incluye ambas funciones FKT_2 ZLL y FKT_2 EU. Al cruzar la frontera se evita así tener que cargar software de control específico del país; al cruzar la frontera simplemente se produce un cambio de función. La segunda función específica del país FKT_2 ZLL consigue la aprobación del país de destino y se muestra mediante la suma de comprobación global HGES_ZLL.
Al mismo tiempo se mantiene la aprobación UE, ya que su segunda función FKT_2 EU = FKT_2 permanece sin cambios, es decir, la suma de comprobación global HGES_EU = HGES no cambia.
La figura 4 muestra, con referencia a la figura 3, una configuración ventajosa del procedimiento según la invención. Con respecto a la salida respectiva de la segunda función FKT_2 EU o FKT_2 ZLL se realiza una selección específica del país.
Esta selección se realiza mediante un bloque de selección MERGER.
El bloque de selección MERGER se utiliza cuando todas las funciones aguas arriba, es decir, en este caso FKT_1, FKT_2 EU y FKT_2 ZLL, se han calculado en paralelo con referencia al bloque de selección MERGER y los respectivos resultados de las funciones están disponibles para su selección para una función aguas abajo del bloque de selección MERGER, en este caso FKT_3.
Dependiendo de la red viaria, el bloque de selección MERGER se controla mediante un identificador de país Netz_ID. Para el bloque de selección MERGER, el identificador de país Netz_ID = ZLL cuando el vehículo ferroviario se encuentra en el país de destino.
En consecuencia, para el bloque de selección MERGER, el identificador de país Netz_ID = EU cuando el vehículo ferroviario se encuentra en países europeos.
Si el vehículo ferroviario se encuentra en el país de destino ZLL, los resultados de la segunda función FKT_2 ZLL calculados se comunican desde el bloque de selección MERGER a través del identificador de red Netz_ID = ZLL a la función FKT_3.
Si el vehículo ferroviario se encuentra en los países europeos, los resultados de la segunda función FKT_2 EU calculados se comunican desde el bloque de selección MERGER a través del identificador de red Netz_ID = EU a la función FKT_3.
Al determinar la estructura STR, la búsqueda de puntos de bifurcación comienza con el bloque de selección MERGER. Las conexiones detectadas a través de los puntos de bifurcación se sustituyen y se calcula una suma de comprobación de la estructura HSTR.
Esto se consigue, por ejemplo, determinando las subredes que se encuentran aguas arriba del bloque de selección MERGER:
Subred 1: FKT_1 -> FKT_2 EU
Subred 2: FKT_1 -> FKT_2 ZLL
Estas dos subredes se cruzan para determinar un origen común o un punto de intersección común.
En este caso se trata de la primera función FKT_1, por lo que en el lado de salida debe tener un punto de bifurcación, es decir, el punto de bifurcación VZWP1.
El bloque de selección MERGER no influye en sí mismo en la estructura STR, es de funcionalmente neutro y solo se utiliza para la selección específica del país de funciones, en este caso las funciones FKT_2 EU y FKT_2 ZLL.
Esto significa que el bloque de selección MERGER no influye en la suma de control HSTR, que es idéntica tanto para los países europeos como para el país de destino.
El ejemplo de software de control que se muestra en este caso en las figuras anteriores se ha elegido y representado de una manera muy simplificada. En el caso de un software de control complejo, según el flujo de señales, al determinar las subredes se debe contar con un gran número de puntos de intersección o puntos de bifurcación, que deben determinarse y tenerse en cuenta.
Puntos de intersección no idénticos indican estructuras diferentes, lo que dará como resultado sumas de comprobación de estructura correspondientemente diferentes.
La figura 5 muestra, con referencia a la figura 4, un perfeccionamiento ventajoso del procedimiento según la invención. Con respecto a la salida de la primera función FKT_1 y en relación con las entradas de las segundas funciones FKT_2 EU y FKT_2 ZLL, se interpone un bloque de división SPLITTER.
El bloque de división SPLITTER pone los resultados de la primera función FKT_1 a disposición de las dos funciones descendentes FKT_2 EU y FKT_2 ZLL, que calculan los respectivos resultados basándose en ello.
El bloque de división SPLITTER no influye en la estructura STR, es de funcionalmente neutro y solo se utiliza para la división.
Esto significa que el bloque de división SPLITTER no influye tampoco en la suma de control HSTR, que es idéntica tanto para los países europeos como para el país de destino.
En resumen, en la invención se determina una estructura para sus funciones interconectadas con referencia al software de control.
Para la estructura, se determina o calcula una suma de comprobación dependiente de la estructura como "hash". La suma de comprobación dependiente de la estructura indica unívocamente una naturaleza asociada de la estructura. Para cada función del software de control se determina o calcula una suma de comprobación dependiente de la función como "hash".
La suma de comprobación dependiente de la función indica unívocamente el contenido o la naturaleza de la función. A partir de las sumas de comprobación dependientes de la función y de la suma de comprobación dependiente de la estructura se determina o calcula una suma de comprobación global, que representa una huella digital unívoca para el software de control.
La suma de comprobación global indica así unívocamente el contenido o la naturaleza del software de control. Una suma de comprobación global sin cambios indica que el software de control no ha cambiado y no es necesario volver a comprobarlo ni aprobarlo nuevamente.
Una suma de comprobación global modificada indica un software de control modificado que debe comprobarse y aprobarse.

Claims (8)

REIVINDICACIONES
1. Procedimiento para identificar y verificar un software de control de un vehículo ferroviario,
- en el que el software de control está formado por funciones (FKT_1,...), cumpliendo cada función (FKT_1,...) una tarea que se le ha asignado en cada caso,
- en el que las funciones (FKT_1,...) en su conjunto interconectadas forman una estructura (STR) del software de control,
- en el que para cada función (FKT_1,...) se crea una suma de comprobación dependiente de la función (HFKT_1,...),
- en el que para la estructura (STR) se crea una suma de comprobación dependiente de la estructura (HSTR), - en el que a partir de las sumas de comprobación dependientes de la función (HFKT_1,...) y de la suma de comprobación dependiente de la estructura (HSTR) se crea una suma de comprobación global (HGES) para el software de control,
- de modo que la suma de comprobación global (HGES) identifica y verifica el software de control para su aprobación en un país (UE, ZLL).
2. Procedimiento según la reivindicación 1,
- en el que, si las funciones (FKT_1,...) y si la estructura (STR) del software de control permanecen sin cambios, se forma una suma de comprobación global (HGES_EU) que indica que el software de control no ha cambiado, - en el que, en el caso de un cambio específico del país (ZLL) en el software de control, se forma una función específica del país (FKT_2 ZLL) a partir de una función sin cambios (FKT_2 EU) seleccionada, modificando la función,
- en el que, al formar la función específica del país (FKT_2 ZLL), se forma una suma de comprobación global específica del país (HGES_ZLL), que difiere de la suma de comprobación global (HGES_EU) del software de control sin cambios.
3. Procedimiento según la reivindicación 1 o 2,
- en el que, si las funciones (FKT_1,...) y la estructura (STR) del software de control permanecen sin cambios, se forma una suma de comprobación global (HGES_EU) que indica que el software de control no ha cambiado, - en el que, en el caso de un cambio específico del país (ZLL) en la estructura (STR) del software de control, se forma una estructura específica del país (STR),
- en el que, al formar la estructura específica del país (STR), se forma una suma de comprobación global específica del país, que difiere de la suma de comprobación global del software de control sin cambios.
4. Procedimiento según una de las reivindicaciones anteriores,
- en el que, en el software de control, se activa y opera o bien la función específica del país (FKT_2 ZLL) o bien la función sin cambios (FKT_2 EU) mediante un identificador de país (NetzjD),
- en el que, si se activa la función específica del país (FKT_2 ZLL) y la estructura (STR) del software de control permanece sin cambios, se muestra la suma de comprobación global específica del país del software de control para su verificación,
- en el que, si se activa la función sin cambios (FKT_2 EU) y la estructura (STR) del software de control permanece sin cambios, se muestra la suma de comprobación global (HGES_EU) del software de control sin cambios para su verificación.
5. Procedimiento según una de las reivindicaciones anteriores, en el que el identificador de país (Netz_ID) se selecciona en función de la red viaria (EU, ZLL) en la que se encuentra el vehículo ferroviario o en la que entra el vehículo ferroviario.
6. Procedimiento según una de las reivindicaciones anteriores, en el que el identificador de país (Netz_ID) y/o un número de versión correspondiente del software de control, que se basa en la suma de control global (HGES_EU, HGES_ZLL) del software de control se muestra al conductor del vehículo ferroviario para fines de control.
7. Procedimiento según una de las reivindicaciones anteriores,
- en el que, en el software de control, una primera función (FKT_1) proporciona resultados tanto a la función sin cambios (FKT_2 EU) como a la función específica del país (FKT_2 ZLL) como funciones descendentes (FKT_2 EU, FKT_2 ZLL),
- en el que las dos funciones descendentes (FKT_2 EU, FKT_2 ZLL) determinan resultados respectivos, - en el que, sin embargo, utilizando el identificador de país (Netz_ID), que actúa sobre un bloque de selección (MERGER), solo uno de los resultados se transmite a otra función (FKT_3).
8. Procedimiento según una de las reivindicaciones anteriores,
- en el que se detectan puntos de bifurcación al determinar la estructura (STR) en el recorrido de las señales del software de control,
- en el que se sustituyen las conexiones detectadas a través de los puntos de bifurcación para calcular la suma de comprobación de la estructura (HSTR).
ES21701903T 2020-02-03 2021-01-13 Procedimiento para identificar y verificar un software de control de un vehículo ferroviario Active ES2957168T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020201257 2020-02-03
PCT/EP2021/050534 WO2021156027A1 (de) 2020-02-03 2021-01-13 Verfahren zur kennzeichnung und verifizierung einer steuerungssoftware eines schienenfahrzeugs

Publications (1)

Publication Number Publication Date
ES2957168T3 true ES2957168T3 (es) 2024-01-12

Family

ID=74285429

Family Applications (1)

Application Number Title Priority Date Filing Date
ES21701903T Active ES2957168T3 (es) 2020-02-03 2021-01-13 Procedimiento para identificar y verificar un software de control de un vehículo ferroviario

Country Status (8)

Country Link
US (1) US20230058071A1 (es)
EP (1) EP4073650B1 (es)
CN (1) CN115039078A (es)
DK (1) DK4073650T3 (es)
ES (1) ES2957168T3 (es)
FI (1) FI4073650T3 (es)
PL (1) PL4073650T3 (es)
WO (1) WO2021156027A1 (es)

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100202346A1 (en) * 2009-02-12 2010-08-12 Sitzes Ryan Z Wireless communication system and method
CA2726781A1 (en) * 2010-12-29 2012-06-29 Evgeny Lishak Methods of offline fare collection for open-loop and hybrid card systems
DE102012023481A1 (de) * 2012-10-30 2014-04-30 Volkswagen Aktiengesellschaft Vorrichtung, Verfahren und Computerprogramm zur räumlichen Darstellung eines digitalen Kartenausschnitts
US20160294605A1 (en) * 2014-07-07 2016-10-06 Symphony Teleca Corporation Remote Embedded Device Update Platform Apparatuses, Methods and Systems
US9841970B2 (en) * 2015-01-13 2017-12-12 Ford Global Technologies, Llc Vehicle control update methods and systems
US9952851B2 (en) * 2015-03-10 2018-04-24 International Business Machines Corporation Intelligent mobile application update
DE102016205827B3 (de) * 2016-04-07 2017-08-17 Volkswagen Aktiengesellschaft Verfahren, Vorrichtung, Fahrzeug und Zentralstelle zum Feststellen einer Aktualität einer lokalen Benutzereinstellung
US20180024826A1 (en) * 2016-07-19 2018-01-25 Ford Global Technologies, Llc Vehicle region-specific software updates distribution
EP3652721A1 (en) * 2017-09-04 2020-05-20 NNG Software Developing and Commercial LLC A method and apparatus for collecting and using sensor data from a vehicle
US11245583B2 (en) * 2018-05-03 2022-02-08 Micron Technology, Inc. Determining whether a vehicle should be configured for a different region
WO2020223684A1 (en) * 2019-05-01 2020-11-05 Swift Navigation, Inc. Systems and methods for high-integrity satellite positioning
US11928898B2 (en) * 2019-12-13 2024-03-12 Autolab Inc. Systems and methods for facilitating vehicle related problems

Also Published As

Publication number Publication date
FI4073650T3 (fi) 2023-12-11
CN115039078A (zh) 2022-09-09
WO2021156027A1 (de) 2021-08-12
DK4073650T3 (da) 2023-11-06
EP4073650B1 (de) 2023-09-13
EP4073650A1 (de) 2022-10-19
PL4073650T3 (pl) 2024-02-19
US20230058071A1 (en) 2023-02-23

Similar Documents

Publication Publication Date Title
US9916151B2 (en) Multiple-stage secure vehicle software updating
CN111066303B (zh) 与机动车辆驾驶员辅助系统相关的方法
US5475753A (en) Apparatus and method for certifying the delivery of information
KR20100100842A (ko) 디지털 맵의 검증
KR101783838B1 (ko) 지적전산자료의 성과 검사 방법
ES2957168T3 (es) Procedimiento para identificar y verificar un software de control de un vehículo ferroviario
US10001381B2 (en) Presentation plan creation apparatus, information presentation apparatus, and presentation plan creation method
CN106529301A (zh) 车机系统的控制方法、装置以及车机系统
CN110647740A (zh) 一种基于tpm的容器可信启动方法及装置
CN112700246B (zh) 基于区块链的数据处理方法、装置、设备及可读存储介质
CN109189859B (zh) 区块链网络中的节点初始化方法和装置
CN109782744A (zh) 一种自动驾驶汽车故障分析方法、装置和介质
CN115135961A (zh) 具有增强型功能安全的数字地图数据
CN107985348B (zh) 一种控制方法和列车运行控制系统
EP4013002A1 (en) Software package transmission method, software package transmission verification method, network device, and storage medium
CN103095698B (zh) 客户端软件的修复方法、装置和通信系统
US20230069564A1 (en) Method for identifying and verifying control software of a rail vehicle
CN112347467B (zh) 车载控制器的启动方法及系统
CN112737793B (zh) 一种更新区块链域名配置的方法和装置
Cho et al. Application of dijkstra's algorithm in the smart exit sign
CN113162889B (zh) 路由更新信息的认证方法及装置
CN114580033A (zh) 一种车载设备标识生成方法、装置及电子设备
WO2021205655A1 (ja) 車載制御システムおよび異常診断方法
CN114537482B (zh) 轨道交通信息数据的校验方法、校验装置和存储介质
CN110727498A (zh) 一种虚拟网络功能的管理方法、nfvo、区块链节点及mano网元