WO2022117306A1 - Procédé assurant la disponibilité de données de programme à partir d'une base de données - Google Patents

Procédé assurant la disponibilité de données de programme à partir d'une base de données Download PDF

Info

Publication number
WO2022117306A1
WO2022117306A1 PCT/EP2021/081377 EP2021081377W WO2022117306A1 WO 2022117306 A1 WO2022117306 A1 WO 2022117306A1 EP 2021081377 W EP2021081377 W EP 2021081377W WO 2022117306 A1 WO2022117306 A1 WO 2022117306A1
Authority
WO
WIPO (PCT)
Prior art keywords
program data
requirements
integration
computing system
information
Prior art date
Application number
PCT/EP2021/081377
Other languages
German (de)
English (en)
Inventor
Sabine Wenz
Original Assignee
Robert Bosch 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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2022117306A1 publication Critical patent/WO2022117306A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to a method for providing program data from a database provided on a computing system, as well as a computing system and a computer program for executing it.
  • Quality checks or "quality gates" to be passed during development and before delivery of the software are usually anchored in the manufacturer's software development process and are therefore independent of the requirements of the functional safety standards.
  • the invention deals with the provision of program data from a database provided on a computer system, in particular in the so-called cloud, i.e. a server that can be reached via the Internet, for example, for downloading by a user, for example.
  • the program data can in particular include software such as a software application or a function thereof, but also only data that is used, for example, in the context of such software applications or functions, e.g. maps or application curves.
  • program data that is to be used for example, for control devices in vehicles or other machines, is or should be made available in this way is the idea that a development platform can be created, the companies involved (which provide the program data, i.e. e.g. developing software) offers the possibility to host your program data (centrally) and then provide or release it to customers or users on request. For this purpose, however, compliance with safety standards must be guaranteed across all manufacturers.
  • the manufacturers or developers of a software application or other program data are usually not aware of the end customer's security requirements for the software application or program data and therefore usually have no direct interest in verifying one or more domain-specific standards.
  • program data such as functions of and data for software applications are directly or indirectly subject to certain functional safety requirements.
  • a direct reference exists if the program data, such as a software application or a function provided by it, itself has a certain risk potential or is used to avert a risk potential. This includes, for example, software applications that cause steering movements in a vehicle or access the brakes.
  • connection if program data such as a software application or a function provided by it does not itself have any potential risk or is used to avert such a risk, but is used in connection with such a software application or function.
  • An example of this would be the measurement or display of distances, eg to the next obstacle in front of a vehicle. Although this is not safety-relevant per se, it is required for safety-relevant functions such as braking in good time.
  • Another indirect reference is when the program data is stored in a software-hardware unit (e.g. in a control unit or an encapsulated part thereof, but also on any other memory such as a database) together with other program data such as a software application or one of these provided function that has a potential risk or is used to avert such. From the point of view of functional safety and the safety and integrity requirements derived from it, this aspect is particularly critical. It is assumed (or must be assumed) that any program data that is located in a software-hardware unit with other program data, software applications or functions without proven separation will "contaminate" them with regard to the guaranteed security requirements.
  • program data such as a software application from a database provided on a computing system for e.g. later downloading
  • the computing system i.e. from the cloud or the underlying server or server network, so to speak.
  • the computer system must be integrated into a network.
  • the program data must have been received by the computing system beforehand, as well as, for example, reference data with information about the program data and about security requirements for the program data.
  • the program data are temporarily stored in an input area provided by the computer system separately from the database (on which the program data are initially stored).
  • a request can come, for example, from a customer or user who wants to download the program data and upload or integrate it into a control unit or other system. This can be done, for example, via a PC and the Internet, an app or the like.
  • requests for the program data are received, ie requests that the user or his system for which the program data is provided has or needs.
  • this comparison can also include other data and/or information that is available in the input area and that, for example, has been entered manually or has also reached the input area in some other way in connection with the setting of the program data.
  • this security directory is in particular correlated with the program data and was generated, for example, when the program data was entered in the database.
  • Such a security directory can in particular serve as proof that the program data meet certain criteria, in particular with regard to security requirements.
  • the information about the program data includes, for example, the responsible manufacturer of the program data, standards used, the version of the program data, a unique identifier for the version and the catalogs supplied (“(context catalogue", “security requirements "Catalogue”, see also below) (for e.g. cryptographic checksums), times, validity, or self-classification of the software integrity level of the program data. In general, one can also speak of a "context catalogue”.
  • the information about the security requirements for the program data include, for example, a description of the conformity with safety requirements from applicable standards, e.g. DIN EN ISO25519 for agriculture, DIN EN ISO 13849 for machines or DIN EN ISO26262 for automotive.
  • This review or this comparison can also be carried out in several stages, i.e. first one aspect of the requirement is queried and checked and then - but possibly only if this first aspect is fulfilled - another aspect. Exemplary topics or requirements that are checked or addressed here are described below.
  • the user can, for example, query the planned application or use case, which is compared with the areas (domains) of the program data permitted according to the safety directory.
  • an integrity level the user can, for example, specify a required integrity level (which he, for example, for his Application required) are queried, which is compared with the integrity level of the program data available according to the security directory.
  • the user can, for example, query the regulatory compliance required according to the security directory (e.g. certain security or other requirements that are required in the desired country of use), which can then be compared with the regulatory compliance documented according to the security directory, required additional measures, or explicit Exclusion criteria are compared.
  • the user can, for example, query the required parameter values for the individual functions of the program data, which are then compared with the parameter values documented for this in accordance with the security directory.
  • the program data will be made available for download (or further use).
  • a provision directory is created in particular, which includes information about the review and is made available for download together with the program data.
  • the program data can then also be removed or deleted from the input area, but in particular only after they have been downloaded or obtained from the user.
  • the information that the provision directory includes can be, for example, the following: an identifier of the checked program data or software, an identifier of a provision or deployment protocol, boundary conditions (e.g. provision target, end user, date; the user can, for example, boundary conditions insofar influence, as who wants to use the program data in certain countries or for a certain period of time or for a certain purpose) of the review and/or provision, a detailed result of the review, in particular including the classification of the safety requirement or the safety integrity level for the reviewed Standards, as well as permissible target markets, and a coded, short result with the boundary conditions.
  • the complete deployment directory i.e. a kind of "deployment catalogue" can also be sent directly to the user or end user.
  • the short result can, for example, be sent to the development goal, ie the system or the computing unit into which the program data is to be integrated.
  • the program data or the software can be released; a corresponding note can be inserted in a header of the program data, for example.
  • the program data can then (with the changed header) be transferred or transmitted to the deployment target.
  • the provision log mentioned can be transferred to the entrance area.
  • the provision log includes, for example, information about the review, the reference data and the requirements. As mentioned, the program data can then be removed or deleted from the input area.
  • an error directory or an error report (“Error Log") is created and made available for download.
  • the program data are then also removed or deleted from the input area, but without having been downloaded, and in particular without being able to download them.
  • the information that the error directory includes can be, for example, the following: an identifier of the checked program data or software, an identifier of the provision or deployment protocol, boundary conditions (e.g. provision target, end user, date) of the verification and/or provision , and a result of the review, in particular including the reason for the negative evaluation.
  • the error directory can be transferred to the end user, the provision log can be transferred to the inbox, the program data can, as mentioned, be removed or deleted from the inbox.
  • the provision log can be created. As already mentioned, this includes, for example, information about the review, the reference data and the requirements. This can also include a link to the security directory, for example, which contains a risk analysis of the requested program data. Also a protocol of the equal to the requirements can be included. The provision log can then be evaluated and archived.
  • an integration directory is preferably provided, which includes information about tests and/or measures for integrating the program data on a computing unit or a system, and provided together with the program data for downloading.
  • the integration can also be controlled by the user or on his computing unit or system.
  • test data and/or test vectors can also be provided for this purpose in the input area.
  • test vectors can be understood to mean structured collections of data with which specific test sequences are defined. These can include, for example, what storage space is required, what input data is required, and what the result should be.
  • the tests and measures included in the integration directory and, in particular, required for the integration can be divided into three groups: first, tests and measures to ensure functional security before the integration is completed, second, tests and measures to ensure software integrity, and third , tests or measures during the runtime of the program data on the system concerned.
  • the tests or measures prior to a final integration should be carried out by the user, logged in the format described and transferred to the computer system. In particular, they then become part of an integration protocol and may be required in order to receive an integration release.
  • Information about an integration carried out according to the integration directory is then received by the computing system. This information can then be checked for specified requirements and, if the requirements are met, the integration release for the program data in relation to the processing unit or the system can be issued or provided. It is useful if the integrity Ration release is only granted if the program data, as mentioned above, has been released for the provision, e.g. a corresponding note has been inserted in the header of the program data.
  • an error directory or error log can be created again.
  • the integration has failed. In both cases, however, an integration log can be created.
  • tests or measures mentioned to ensure the software integrity and the tests or measures during the runtime can also be carried out.
  • the tests or measures to ensure the software integrity may require the end user to carry out a composition analysis, for example. This determines which functions use the provided program data or software. If the users are functions that were provided and transferred in the same process, these functions have, for example, a function-based risk assessment that can be obtained via the provisioning protocol and the risk analysis linked here.
  • composition evaluation can then be created, which lists the system functions and the integrity level with the functions they use and deliver and their integrity level. This list may be part of the integration directory.
  • the end user can request data for a system risk analysis ("Hazard and Risk Analysis”), for example.
  • the computing system can access the risk analysis of the provisioning directory and create a composition risk analysis.
  • This consists, for example, of a representation of the program data provided, including risk data, an identification of the functions used from the transferred program data as well as an identification of the composition including evaluation. This can be stored in the integration directory and used by the end user to create a system risk analysis.
  • test data and data for the analysis mentioned can be requested by the user during runtime and made available for functional validation in the same way as the test data. They contain, for example, test data or test vectors for checking the functionality during runtime or on the deployment target (self-test), and limit values for checking and restricting input parameters during runtime.
  • a checksum can be formed for the existing code and compared with a reference value, or (simple) tests can also be carried out with certain input data and a comparison of the output data with reference data.
  • the integration log can be created again, which, for example, contains all information from the integration directory and the error directory. It may also contain a link to the Security Directory, which contains the risk analysis of the requested program data, and a log of the communication between the end-user or delivery target and the front end. The integration log can then be evaluated, for example, for an analysis of customer behavior and then archived.
  • a computing system e.g. a server, is set up, in particular in terms of programming, to carry out a method according to the invention.
  • Suitable data carriers for providing the computer program are, in particular, magnetic, optical and electrical memories, such as hard drives, flash memories, EEPROMs, DVDs, etc. It is also possible to download a program via computer networks (Internet, intranet, etc.).
  • FIG. 1 schematically shows a sequence of a method according to the invention in a preferred embodiment.
  • FIG. 2 schematically shows a sequence of a method according to the invention in a further preferred embodiment.
  • FIG. 1 shows a sequence of a method according to the invention in a preferred embodiment, specifically using a computing system 120 that is set up accordingly.
  • a manufacturer or provider 100 wants to make program data 110, e.g. a software application or function or specific data for this, available to customers in e.g. a current version of, for example, a specific software application for a control unit of a vehicle or a specific function for this.
  • program data 110 e.g. a software application or function or specific data for this
  • the provider 100 also makes reference data available, which on the one hand includes information 112 about the program data 110 and information 114 about security requirements for the program data 110 .
  • the information 112 about the program data 110 can be, for example, the responsible manufacturer (this can be one, but several manufacturers are also conceivable) of the program data, standards used, the version of the program data, a unique identifier for the version and the catalogs supplied, dates, validity, or self-assessment of the software integrity level of the program data.
  • the information 112 thus represents a "context catalog”.
  • the information 114 about security requirements for the program data 110 can, for example, include a description of the conformity with security requirements from applicable standards. For the example of a vehicle, this is e.g. DIN EN ISO26262 for automotive.
  • the program data 110 is then stored in the database 130 or in a special sub-area 124 for the corresponding security requirements (the sub-areas 126, 128 are provided for other security requirements).
  • the computing system 120 creates a safety directory 150, which includes, for example, all information 112 and 114, as well as, for example, a date and a result of the review, possibly also a classification of the safety requirement for the standards reviewed.
  • the proposed method relates in particular to the provision of this program data 110 from the database 130 for a customer or user 165 who wants to download this program data 110 to a system 160 (or a control unit) and integrate it there.
  • the user - or possibly also automatically the system 160 - makes a request 140 for the provision of the program data 110 to the computer system 120.
  • This request 140 is received by the computer system 120.
  • the program data 110 from the database 130 are then temporarily stored in an input area 122 (or exchange area) provided by the computing system 120 separately from the database 130 .
  • Demands 152 for the program data are then received by the computing system 120 and a check is made as to whether the demands 152 are met by the program data 110 .
  • the requirements 152 is compared with information from a security directory 150, which includes information 112 about the program data 110 and information 114 about security requirements for the program data 120. As already mentioned, the requests 152 can also be received in several stages or in several steps. If the requirements 152 are met, the program data 110 is made available for downloading by the user 165, for example, or--possibly automated--to the system 160.
  • a provisioning record 142 including information about the verification is created and provided with the program data 110 for download.
  • the information contained in the provision directory can be, for example, an identifier for the checked program data 110, a detailed result of the check and a short result with the boundary conditions (further information has already been mentioned above).
  • the full provisioning directory can also be provided directly to the user 165 .
  • the brief result can, for example, be transferred to the provisioning target, i.e. here the system 160.
  • the program data 110 can be released; for this purpose, a corresponding note 111 can be inserted in a header of the program data, for example.
  • an error directory 143 is created and also made available for downloading or sent directly to transferred to user 165.
  • the program data 110 are then removed or deleted from the input area 122 .
  • a provision log 144 is also created, which includes information about the review, the reference data, and the requirements.
  • the program data 120 can also be integrated into the system 160, for example, as part of the proposed procedure.
  • a sequence of a method according to the invention is shown schematically in FIG. 2 in a further preferred embodiment.
  • the procedure here is similar to that described above; deviations will be explained below (the same components are denoted by the same reference symbols as in FIG. 1).
  • an integration directory 242 is provided that contains information about tests and/or measures for the integration of the program data 100 on the system (this can be, for example, a Arithmetic unit act like a control unit) includes, and is provided together with the program data 110 for downloading for the user 165.
  • the integration directory e.g. the provision directory 142 and possibly a general directory 250 for an integration can be used.
  • the integration can then be carried out automatically by the system 160 or, if necessary, by the user 165 .
  • information 240 about an integration carried out according to the integration register 242 is transmitted to the computing system 120 and received by it. This information 240 is checked against predetermined requirements and, if the requirements are met, an integration release 246 for the program data 110 with respect to the system 160 is issued.
  • the tests and measures mentioned to ensure the software integrity and the tests and measures during runtime can also be carried out.
  • an error directory 243 can be created.
  • a note 211 can then be used to indicate that the integration has failed.
  • an integration log 244 can be created which, for example, contains all the information from the integration directory and possibly the error directory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé assurant la disponibilité de données de programme (110) à partir d'une base de données (130) disponible dans un système informatique (120), ledit procédé comprenant les étapes suivantes qui sont mises en œuvre automatiquement par le système informatique : lors de la réception d'une demande (140) de disponibilité de données de programme (110), stocker temporairement les données de programme (110) dans une région d'entrée (122) rendue disponible par le système informatique (120) séparément de la base de données (130) ; recevoir des exigences (152) pour les données de programme (110) ; vérifier si les données de programme (110) satisfont aux exigences (152), en comparant les exigences avec des informations (112, 114) à partir d'un registre de sécurité (150) qui est disposé dans le système informatique (120) et qui comprend des informations sur les données de programme (110) et sur des exigences de sécurité pour les données de programme (110) ; rendre les données de programme (110) disponibles pour les télécharger vers l'aval si les exigences (152) sont satisfaites.
PCT/EP2021/081377 2020-12-03 2021-11-11 Procédé assurant la disponibilité de données de programme à partir d'une base de données WO2022117306A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020215286.1A DE102020215286A1 (de) 2020-12-03 2020-12-03 Verfahren zum Bereitstellen von Programmdaten aus einer Datenbank
DE102020215286.1 2020-12-03

Publications (1)

Publication Number Publication Date
WO2022117306A1 true WO2022117306A1 (fr) 2022-06-09

Family

ID=78709433

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/081377 WO2022117306A1 (fr) 2020-12-03 2021-11-11 Procédé assurant la disponibilité de données de programme à partir d'une base de données

Country Status (2)

Country Link
DE (1) DE102020215286A1 (fr)
WO (1) WO2022117306A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200012799A1 (en) * 2014-12-09 2020-01-09 International Business Machines Corporation Automated management of confidential data in cloud environments
US20200074104A1 (en) * 2018-08-28 2020-03-05 Ca, Inc. Controlling access to data in a database based on density of sensitive data in the database

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200012799A1 (en) * 2014-12-09 2020-01-09 International Business Machines Corporation Automated management of confidential data in cloud environments
US20200074104A1 (en) * 2018-08-28 2020-03-05 Ca, Inc. Controlling access to data in a database based on density of sensitive data in the database

Also Published As

Publication number Publication date
DE102020215286A1 (de) 2022-06-09

Similar Documents

Publication Publication Date Title
DE102005014273B4 (de) Vergleich von Schnittstellen zwischen Softwarekomponenten
DE102019109672A1 (de) Rückgängigmachung nach einem teilausfall in mehreren elektronischen steuergeräten mittels over-the-air-updates
DE102017211433B4 (de) Verfahren zum Durchführen eines Funktionstests eines Steuergeräts in einem Hardware-in-the-Loop-Test, HIL-Test, sowie HIL-Prüfstand und Steuergerät
DE102016119320A1 (de) Verfahren zum Konfigurieren eines realen oder virtuellen elektronischen Steuergerätes
WO2018206522A1 (fr) Détermination de la maturité d'un système technique et en particulier d'un véhicule circulant de manière autonome
DE102018206762A1 (de) Feature-Development-Framework und Feature-Integration-Framework zum Implementieren physikalischer Funktionsfeatures in einem Zielgerät
EP3732608B1 (fr) Procédé de paramétrage assisté par ordinateur d'un système technique
WO2022117306A1 (fr) Procédé assurant la disponibilité de données de programme à partir d'une base de données
DE10228610A1 (de) Verfahren zum Überprüfen eines auf einer elektronischen Recheneinheit ablaufenden Steuerprogramms
WO2021047970A1 (fr) Composants logiciels pour une architecture logicielle
WO2022117305A1 (fr) Procédé de stockage de données de programme dans une base de données
EP4144003B1 (fr) Procédé de fabrication d'un composant logiciel pour un dispositif informatique électronique d'un véhicule automobile, produit de programme informatique, support de stockage lisible par ordinateur et système de mise à jour externe de véhicule automobile
DE102020107141B4 (de) Simulieren einer Steuergerätekommunikation zwischen einem zu testenden Steuergerät und mindestens einem weiteren Steuergerät
DE102022207085A1 (de) Verfahren zum Erzeugen eines digitalen Zwillings eines autonom fahrenden Kraftfahrzeuges
EP1553524B1 (fr) Préparation et exécution des services par une unité de traitement de données
DE102021005309A1 (de) Verfahren zur Bewilligung der Einbringung von Programmcode aus einem Programmcode-Freigabepaket in eine Anwendungsumgebung und informationstechnisches System
DE102022113104A1 (de) Eindeutige Identitätskennung für Lognachrichtenquellen in Fahrzeugen
DE102016207768A1 (de) Vorrichtung und Verfahren zum Bereitstellen einer Menge von Modultypen
DE102022112550A1 (de) Verfahren zum Anpassen einer Funktionalität einer Softwareapplikation an eine für die Ausführung der Funktionalität verfügbare Hardwareausstattung eines Kraftfahrzeugs sowie computerlesbares Speichermedium und Computersystem
DE102021102460A1 (de) Verfahren zur Durchführung einer Simulation
EP4099163A1 (fr) Procédé et système de détection et de suppression des points de défaillances dans les couches individuelles d'u système de fichiers d'une image de conteneur
DE102022114913A1 (de) Computerimplementiertes Verfahren zur Verwendung von gespeicherten Spezifikationsanteilen
WO2024132503A1 (fr) Procédé et dispositif d'attribution individuelle d'au moins un diagramme de fonction de véhicule à au moins un véhicule
DE102024108126A1 (de) Verfahren zur Nutzung von unbekannten neuen Systemdiensten in einer Fahrzeuganwendung
WO2021105103A1 (fr) Procédé et outil logiciel pour la réalisation de spécifications exécutables dans le développement d'un système ou la validation d'un système de systèmes fonctionnels complexes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21810981

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21810981

Country of ref document: EP

Kind code of ref document: A1