WO2008138770A1 - Verfahren zum rechnergestützten wissensschutz eines software-systems - Google Patents

Verfahren zum rechnergestützten wissensschutz eines software-systems Download PDF

Info

Publication number
WO2008138770A1
WO2008138770A1 PCT/EP2008/055380 EP2008055380W WO2008138770A1 WO 2008138770 A1 WO2008138770 A1 WO 2008138770A1 EP 2008055380 W EP2008055380 W EP 2008055380W WO 2008138770 A1 WO2008138770 A1 WO 2008138770A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
modified
software components
component
code
Prior art date
Application number
PCT/EP2008/055380
Other languages
English (en)
French (fr)
Inventor
Markus Brenner
Michael Golm
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2008138770A1 publication Critical patent/WO2008138770A1/de

Links

Classifications

    • 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/125—Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading

Definitions

  • the invention relates to a method for computer-aided knowledge protection of a software system, in particular according to AUTOSAR standard, which comprises a plurality of software components with respective software code, which are at least partially coupled to each other at interfaces of the software components, wherein for respective software components and interfaces component descriptions are provided.
  • the basic idea of the method according to the invention is to merge several software components into one atomic software component. This procedure removes architectural information from the component descriptions, obscuring the exact structure of the modified software component (i.e., the atomic component). The merging of the component descriptions leads to a reduction to the exterior view of the modified software component. It is not clear from which individual software components the modified software component exists.
  • the software code of the subset of the plurality of software components is processed into a modified software code.
  • a modified runtime environment a so-called. Runtime Environment (RTE) is also created for the modified software component.
  • RTE Runtime Environment
  • mapping is also known to a person skilled in the art by the term "mapping".
  • the software code of a respective software component comprises implementation data
  • code segments are created for all interfaces of the software components during processing in accordance with a specification of the runtime environment.
  • runtime environment events that occur within the modified software component generate a local runtime environment code.
  • Local in this context means that the runtime environment code is generated for the modified software component.
  • compositions comprising a plurality of software components, resolved.
  • Hierarchies of compositions that become part of the modified software component are expanded to a flat structure, eliminating all the interfaces of the original description.
  • triggered event are triggered or globally triggered.
  • all the summarizable code sequences of the software components that can be summarized in the modified software component are combined in the modified software component. Code sequences are summarized if they belong to category 1 and have the same activation period.
  • a code sequence (referred to as RunnableEntity in AUTOSAR) is category 1 if it requires uninterrupted flow. It is also useful to consider formulated constraints on the execution order of the code sequences in the merge.
  • the invention also includes a computer program product that can be loaded directly into the internal memory of a digital computer and includes software code portions that perform the steps of the previously described method when the product is run on a computer.
  • the inventive method allows the merging of structural information of a plurality of software components for a software system, whereby a protection of implemented in the software components algorithms and ideas is possible.
  • the method also allows the use of the AUTOSAR standard developed in the automotive environment for the development of the internal structure of a software system.
  • the procedure prevents the exchange of information relevant to a party involved, so-called external view, from the software involuntarily issuing the expert's knowledge of the internal structure of the software system as described in the original component description (AUTOSAR: XML description) ,
  • AUTOSAR XML description
  • Fig. 1 is a schematic representation of a plurality
  • Fig. 2 is a schematic representation, on the basis of the steps performed in the method according to the invention will become apparent.
  • a plurality of software components 1 are shown in the left half.
  • the software components 1 are referred to as "Atomic Software Component Type.”
  • some of the software components 1 are combined into a software composition 6 (in AUTOSAR: “CompositionType”).
  • Some of the software components 1 are related to each other.
  • so-called connectors 2 are provided between software components 1 which are related to one another.
  • the reference numeral 3 denotes respective ports of the software components 1.
  • Ports of the software composition 6, which enable a connection to software components 1 outside the software composition 6, are identified by the reference numeral 4.
  • Connecting lines 8, which run between ports 3 of the software component 1 and the ports 4, are referred to in the AUTOSAR standard as "DelegationConnector".
  • the software components 1 encompassed by the software composition 6 are to be processed into a modified software component 7 so that no structural information about the software components contained in the modified software component 7 is obtained after the execution of the processing. Components 1 and their respective component descriptions are visible.
  • the modified one Software component 7 is also referred to as an atomic component.
  • the procedure for processing or merging the software components 1 included in the software composition into the modified software component 7 comprises the following steps:
  • modified software component which is referred to as a modified component description, merely contains information about the connections to other software components to be made at the outer ports 4.
  • a description of the connections of the software processed in the modified software component 7 However, ware components can not be found in this modified component description.
  • the procedure carried out in the context of the method according to the invention will be better understood.
  • the steps taken by a first party A are identified by the reference symbol A.
  • the steps made by a party B are indicated by the reference letter B.
  • Party A develops software and delivers it to Party B for integration into a larger software system.
  • Party A uses the procedure described in this invention to remove architectural information from the software components it has created.
  • the software developed by Party A includes a number of software components. For each of the software components, interface data 10, implementation data 11, and component descriptions 12 are created.
  • the interface data 10 is contained in a header file.
  • the implementation data 11 are respectively stored in e.g. included in a C-Fi.
  • the interface data 10 and the implementation data 11 are each converted into modified interface data 13 and modified implementation data 14.
  • the component descriptions 12 are converted by a modifier 17 into a single modified component description 15.
  • the modification means 17 carries out the following steps:
  • Hierarchies of compositions comprising a plurality of software components, within an outer composition
  • CompositionType are expanded to a flat structure, eliminating the Delegation 4 connector of the original description.
  • RTE events runtime environment events
  • a local RTE code is generated.
  • Code sequences are mergable if they belong to category 1 and have the same activation period.
  • Category 1 means that a code sequence requires uninterrupted processing.
  • Formulated constraints are taken into account in the execution order of the runable entities at the merge.
  • a local runtime environment 16 (“local_RTE (C)") is generated by the modification means 17.
  • the runtime environment 16 is processed together with the modified implementation data 14 and the modified interface data 13 to form a modified software component.
  • the resulting result is an object file 18, which is supplied to the party B together with the modified component description 15.
  • the modified component description 15 is in this case supplied to a runtime environment creation means ("RTE generator") which creates an interface data file 21 ("h") as well as an implementation data file 22 which also includes a runtime environment (“C (RTE)”.)
  • RTE generator runtime environment creation means
  • the interface data file 21 as well as the implementation data file 22 supplied together with the object file 18 to a means 23 for generating the software system. This is also known as the build process.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)

Abstract

Es wird ein Verfahren zum rechnergestützten Wissensschutz eines Software-Systems, insbesondere gemäss dem AUTOSAR-Standard, beschrieben, welches eine Mehrzahl an Software-Komponenten (1) mit jeweiligen Software-Code umfasst. Die Software-Komponenten (1) sind zumindest teilweise an Schnittstellen (3, 4) der Software-Komponenten (1) miteinander gekoppelt, wobei für jeweilige Software-Komponenten (1) und Schnittstellen (3, 4) Komponentenbeschreibungen (12) vorgesehen sind. Es wird zumindest eine Teilmenge der Mehrzahl an Software-Komponenten (1) zu einer modifizierten Software-Komponente (18) verarbeitet, wobei für die modifizierte Software-Komponente (18) und die Schnittstellen (4) der modifizierten Software-Komponenten (18) zu den übrigen Software-Komponenten (1) jeweils modifizierte Komponentenbeschreibungen (15) erstellt werden.

Description

Beschreibung
Verfahren zum rechnergestützten Wissensschutz eines Software-Systems
Die Erfindung betrifft ein Verfahren zum rechnergestützten Wissensschutz eines Software-Systems, insbesondere gemäß AU- TOSAR-Standard, welches eine Mehrzahl an Software-Komponenten mit jeweiligem Software-Code umfasst, die zumindest teilweise an Schnittstellen der Software-Komponenten miteinander gekoppelt sind, wobei für jeweilige Software-Komponenten und Schnittstellen Komponentenbeschreibungen vorgesehen sind.
Bei der Entwicklung komplexer Rechnersysteme, welche eine Vielzahl an einzelnen Rechnern oder Steuergeräten umfassen, spielt der Austausch von Software-Komponenten über die Grenzen einer Vielzahl von an der Entwicklung des Software-Systems beteiligten Personen und Firmen eine große Rolle. Um ein reibungsloses Zusammenspiel der später zu dem Software-System zusammengeführten Software-Komponenten sicherzustellen, entstanden Standards, die Schnittstellen und Interaktionen von Software-Komponenten genau und formal in einer vorgegebenen Form spezifizieren .
Ein solcher Standard wurde beispielsweise in der Automobilindustrie entwickelt und ist unter dem Namen AUTOSAR bekannt. In diesem sind Schnittstellen und Interaktionen der Software-Komponenten in Form von XML-Beschreibungen spezifiziert. XML steht für Extendable Markup Language . Um die Vorteile der AUTOSAR-Entwicklungsmethodik voll ausnutzen zu können, muss eine Software-Komponente auch über rein externe Schnittstellen zu anderen Software-Komponenten hinaus intern mit Beschreibungsmitteln, die in dem Standard AUTOSAR definiert sind, strukturiert werden. Diese Methodik erfordert es, dass die XML-Beschreibungen bei der System-Integration zur Erzeugung einer Laufzeitumgebung, die auch als Runtime-Environment (RTE) Middleware bezeichnet wird, zur Verfügung stehen. Hierdurch lässt sich jedoch nicht vermeiden, dass in einer Soft- ware-Komponente enthaltene Ideen gegenüber den anderen Beteiligten bei der Entwicklung des Software-Systems offengelegt werden .
Bislang wurde der Schutz von in Software-Code enthaltenen Ideen durch die Übersetzung der Software in ein binäres Objektformat realisiert. Ein derartiger Schutz ist zwar auch bei dem oben beschriebenen AUTOSAR basierten Software-System möglich, jedoch werden durch die Übersetzung der Software in ein binäres Ob- jektformat nicht die in den XML-Beschreibungen enthaltenen
Architekturinformationen eingeschlossen, so dass in der Software enthaltene Algorithmen oder Lösungen für bestimmte Probleme weiterhin erkennbar sind.
Eine weitere Möglichkeit, die Preisgabe der internen Struktur des Software-Codes in einer Software-Komponente zu unterbinden besteht darin, diese Struktur nicht mit den im AUTOSAR-Standard definierten Mitteln zu modellieren. Jedoch führt diese Vorgehensweise zu einem Produktivitätsverlust bei der Software- entwicklung, da gerade die Standardisierung und die Vorgabe von Methoden und Werkzeugen zur Architekturdefinition die Entwicklung komplexer Software-Systeme, an der eine Vielzahl unterschiedlicher Personen oder Firmen beteiligt sind, erleichtert .
Es ist daher Aufgabe der vorliegenden Erfindung, eine Möglichkeit anzugeben, mit welcher die oben beschriebenen Nachteile vermieden werden können, so dass bei der Entwicklung eines Software-Systems auf standardisierte Methoden zurückgegriffen werden kann, die in einer Software-Komponente enthaltenen
Strukturinformationen jedoch nicht nach außen offensichtlich werden .
Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Ausführungsformen ergeben sich aus den abhängigen Ansprüchen. Bei einem erfindungsgemäßen Verfahren zum rechnergestützten Wissensschutz eines Software-Systems, insbesondere gemäß dem AUTOSAR-Standard, welches eine Mehrzahl an Software-Komponenten mit jeweiligem Software-Code umfasst, welche Soft- ware-Komponenten zumindest teilweise an Schnittstellen der Software-Komponenten miteinander gekoppelt sind, wobei für jeweilige Software-Komponenten und Schnittstellen-Komponenten Beschreibungen vorgesehen sind, werden zumindest eine Teilmenge der Mehrzahl an Software-Komponenten zu einer modifizierten Software-Komponente verarbeitet, wobei für die modifizierte Software-Komponente und die Schnittstellen der modifizierten Software-Komponenten zu den übrigen Software-Komponenten jeweils modifizierte Komponentenbeschreibungen erstellt werden.
Die Grundidee des erfindungsgemäßen Verfahrens besteht darin, mehrere Software-Komponenten zu einer atomaren Software-Komponente zu verschmelzen. Durch dieses Vorgehen werden Architekturinformationen aus den Komponentenbeschreibungen entfernt, wodurch der genaue Aufbau der modifizierten Soft- ware-Komponente (d.h. der atomaren Komponente) nicht mehr erkennbar ist. Die Verschmelzung der Komponentenbeschreibungen führt zu einer Reduktion auf die Außenansicht der modifizierten Software-Komponente. Hierbei ist nicht ersichtlich, aus welchen einzelnen Software-Komponenten die modifizierte Soft- ware-Komponente besteht.
Gemäß einer Ausführung wird der Software-Code der Teilmenge der Mehrzahl an Software-Komponenten zu einem modifizierten Software-Code verarbeitet. Zweckmäßigerweise wird ferner für die modifizierte Software-Komponente eine modifizierte Laufzeitumgebung, eine sog. Runtime-Environment (RTE) erstellt. Schließlich ist es zweckmäßig, wenn die modifizierte Laufzeitumgebung mit der modifizierten Software-Komponente in ein binäres Objektformat und damit eine Objektdatei überführt wird.
Gemäß einer weiteren Ausgestaltung des Verfahrens werden die Software-Komponenten, die zu einer modifizierten Software-Komponente verarbeitet werden, auf dasselbe Steuergerät abgebildet. Das Abbilden ist einem Fachmann auch unter dem Begriff des „Mappings" bekannt.
Gemäß einer weiteren Ausgestaltung umfasst der Software-Code einer jeweiligen Software-Komponente Implementierungsdaten
(Nutzerdaten, . c Dateien) und Schnittstellendaten (Headerdaten, .h Dateien) , wobei die Software-Codes der Teilmenge der Mehrzahl an Software-Komponenten zu einem modifizierten Software-Code verarbeitet werden, indem die jeweiligen Implementierungsdaten der Software-Komponenten zu einer modifizierten Implementierungsdatendatei und die jeweiligen Schnittstellendaten der Softwarekomponenten zu einer modifizierten Schnittstellendatendatei verarbeitet werden. Dieser Schritt entspricht der Verschmelzung der Implementierungen der Software-Komponenten zu einer Objektdatei. Die Implementierungen werden bei diesem
Schritt nicht modifiziert, sondern sie werden ummodifiziert zu einem gemeinsamen Objektfile compiliert.
Gemäß einer weiteren Ausgestaltung werden für alle Schnitt- stellen der Software-Komponenten beim Verarbeiten Codesegmente gemäß einer Spezifikation der Laufzeitumgebung erstellt.
Gemäß einer weiteren Ausführungsform wird für Laufzeitumgebungsereignisse, die innerhalb der modifizierten Soft- ware-Komponente ablaufen, ein lokaler Laufzeitumgebungs-Code erzeugt. Lokal bedeutet in diesem Zusammenhang, dass der Laufzeitumgebungscode für die modifizierte Software-Komponente generiert wird.
Gemäß einer weiteren Ausführungsform werden Hierarchien von
Kompositionen, umfassend eine Mehrzahl an Software-Komponenten, aufgelöst. Hierarchien von Kompositionen, welche Teil der modifizierten Software-Komponente werden, werden zu einer flachen Struktur expandiert, wodurch sämtliche Schnittstellen der ursprünglichen Beschreibung entfallen.
Gemäß einer weiteren Ausführungsform werden gleichartige Laufzeitumgebungsereignisse, die durch ein außerhalb der mo- difizierten Software-Komponente ablaufendes Ereignis getriggert werden oder die global getriggert werden, in der modifizierten Software-Komponente zusammengefasst . Zweckmäßigerweise werden alle zusammenfassbaren Codesequenzen der Software-Komponenten, die in der modifizierten Software-Komponente zusammenfassbar sind, in der modifizierten Software-Komponente zusammengefasst . Codesequenzen sind zusammenfassbar, wenn diese der Kategorie 1 angehören und dieselbe Aktivierungsperiode haben. Eine Codesequenz (bei AUTOSAR als RunnableEntity bezeichnet) gehört der Kategorie 1 an, wenn diese einen unterbrechungsfreien Ablauf erfordert. Es ist ferner zweckmäßig, wenn formulierte Beschränkungen auf die Ausführungsreihenfolge der Codesequenzen bei der Verschmelzung berücksichtigt werden.
Von der Erfindung ist ferner ein Computerprogrammprodukt um- fasst, das direkt in den internen Speicher eines digitalen Computers geladen werden kann und Software-Codeabschnitte umfasst, mit denen die Schritte des vorher beschriebenen Verfahrens ausgeführt werden, wenn das Produkt auf einem Computer läuft.
Das erfindungsgemäße Verfahren erlaubt das Verschmelzen von Strukturinformationen einer Vielzahl an Software-Komponenten für ein Software-System, wodurch ein Schutz der in den Soft- ware-Komponenten verwirklichten Algorithmen und Ideen ermöglicht ist. Das Verfahren erlaubt damit den Einsatz des im Automobilumfeld entwickelten Standards AUTOSAR auch für die Entwicklung der internen Struktur eines Software-Systems. Insbesondere verhindert das Verfahren, dass bei einem Austausch der für eine beteiligte Partei relevanten Informationen, sog. Außenansicht, über die Software unfreiwillig auf das in der ursprünglichen Komponentenbeschreibung (AUTOSAR: XML-Beschreibung) dargelegte Expertenwissen über den internen Aufbau des Software-Systems herausgegeben wird. Hierbei wird zum Schutz der Struktur und der Ideen ein Bruch zwischen interner und externer Architekturdefinition vermieden und so ein effizienter Einsatz von AUTOSAR zur vollständigen Architekturbeschreibung möglich . Die Erfindung wird nachfolgend anhand der Figuren näher erläutert. Es zeigen:
Fig. 1 eine schematische Darstellung einer Mehrzahl an
Software-Komponenten, von denen ein Teil zu einer modifizierten Software-Komponente verarbeitet wird, und
Fig. 2 eine schematische Darstellung, anhand der die im erfindungsgemäßen Verfahren durchgeführten Schritte ersichtlich werden.
In Fig. 1 sind in der linken Hälfte eine Mehrzahl an Soft- ware-Komponenten 1 dargestellt. Im Automobilstandard AUTOSAR werden die Software-Komponenten 1 als „AtomicSoftwareCompo- nentType" bezeichnet. Hierbei sind einige der Software-Komponenten 1 zu einer Software-Komposition 6 (in AUTOSAR: „CompositionType") zusammengefasst . Manche der Soft- ware-Komponenten 1 stehen in Relation zueinander. Um diesen Zusammenhang zu illustrieren, sind zwischen in Relation zueinander stehenden Software-Komponenten 1 sog. Connectoren 2 vorgesehen. Mit dem Bezugszeichen 3 sind hierbei jeweilige Ports der Software-Komponenten 1 bezeichnet. Ports der Soft- ware-Komposition 6, welche eine Verbindung mit Software-Komponenten 1 außerhalb der Software-Komposition 6 ermöglichen, sind mit dem Bezugszeichen 4 gekennzeichnet. Verbindungslinien 8, die zwischen Ports 3 der Software-Komponente 1 und den Ports 4 verlaufen, werden im AUTOSAR-Standard als „DelegationConnector" bezeichnet.
Im Ausführungsbeispiel der Fig. 1 sollen die von der Software-Komposition 6 umfassten Software-Komponenten 1 zu einer modifizierten Software-Komponente 7 verarbeitet werden, so dass nach der Durchführung der Verarbeitung keine Strukturinformationen über die in der modifizierten Software-Komponente 7 enthaltenen Software-Komponenten 1 sowie deren jeweiligen Komponentenbeschreibungen ersichtlich werden. Die modifizierte Software-Komponente 7 wird auch als atomare Komponente bezeichnet .
Die Vorgehensweise zur Verarbeitung oder Verschmelzung der von der Software-Komposition umfassten Software-Komponenten 1 zu der modifizierten Software-Komponente 7 umfasst dabei folgende Schritte :
1. Verschmelzung der Komponentenbeschreibungen derart, dass diese auf die Außenansicht der modifizierten Software-Komponente 7 reduziert ist.
2. Verschmelzung der Implementierungen des Software-Codes jeweiliger Software-Komponenten 1, welche von der Software-Komposition 6 umfasst sind. 3. Generierung einer lokalen Laufzeitumgebung, einer sog. Runtime-Environment (RTE) , und Verschmelzung mit den Implementierungen durch eine Übersetzung in ein binäres Objektformat .
Bei der Durchführung der oben bezeichneten Lösungsschritte wird davon ausgegangen, dass die in der modifizierten Software-Komponente verarbeiteten bzw. verschmolzenen Software-Komponente auf ein und demselben Rechner bzw. ein und dasselbe Steuergerät abgebildet bzw. gemappt werden.
Das Ergebnis dieses Vorgehens lässt sich der schematischen Darstellung in der rechten Hälfte der Fig. 1 entnehmen. Hierbei ist ersichtlich, dass bei Betrachtung der modifizierten Software-Komponente 7 keine Information über die in dieser enthaltenen Software-Komponenten und die zwischen diesen
Software-Komponenten realisierten Verbindungen erkenntlich sind. Die Komponentenbeschreibung der modifizierten Software-Komponente, welche als modifizierte Komponentenbeschreibung bezeichnet wird, enthält lediglich Informationen über die an den äußeren Ports 4 vorzunehmenden Verbindungen zu anderen Software-Komponenten. Eine Beschreibung der Verbindungen der in der modifizierten Software-Komponente 7 verarbeiteten Soft- ware-Komponenten ist dieser modifizierten Komponentenbeschreibung jedoch nicht zu entnehmen.
Anhand der Fig. 2 wird das im Rahmen des erfindungsgemäßen Verfahrens durchgeführte Vorgehen besser ersichtlich. Hierbei sind die von einer ersten Partei A vorgenommenen Schritte mit dem Bezugszeichen A gekennzeichnet. In entsprechender Weise sind die durch eine Partei B vorgenommenen Schritte mit dem Bezugszeichen B gekennzeichnet. Partei A entwickelt eine Software und liefert diese an die Partei B zur Integration in ein größeres Software-System. Partei A verwendet dabei die in dieser Erfindung beschriebene Vorgehensweise, um Architekturinformationen aus den von ihr erstellten Software-Komponenten zu entfernen.
Die von der Partei A entwickelte Software umfasst eine Mehrzahl an Software-Komponenten. Für jede der Software-Komponenten werden Schnittstellendaten 10, Implementierungsdaten 11 sowie Komponentenbeschreibungen 12 erstellt. Die Schnittstellendaten 10 sind in einem Header-File enthalten. Die Implementie- rungsdaten 11 sind jeweils in z.B. einem C-FiIe enthalten. Bei der Durchführung des Verfahrens werden die Schnittstellendaten 10 sowie die Implementierungsdaten 11 jeweils in modifizierte Schnittstellendaten 13 sowie modifizierte Implementierungsdaten 14 gewandelt. Ferner werden die Komponentenbeschreibungen 12 durch ein Modifikationsmittel 17 in eine einzige modifizierte Komponentenbeschreibung 15 gewandelt. Das Modifikationsmittel 17 führt dabei folgende Schritte durch:
1. Hierarchien von Kompositionen, umfassend eine Mehrzahl von Software-Komponenten, innerhalb einer äußeren Komposition
(sog. CompositionType) werden zu einer flachen Struktur expandiert, wodurch die Delegation Connectors 4 der ursprünglichen Beschreibung entfallen.
2. Für sämtliche Assembly Connectors 3 werden Codesegmente, sog. Kommunikationsstubs, entsprechend der Spezifikation der Laufzeigumgebung (sog. RTE-Spezifikation) erzeugt.
3. Für Laufzeitumgebungsereignisse (sog. RTE-Events) , die auf einer internen Kommunikation, d.h. einer Kommunikation innerhalb der zu erzeugenden modifizierten Software-Komponente, basieren, wird ein lokaler RTE-Code generiert .
4. Gleichartige RTE-Events, das sind Aktivierungsbedingungen für Codesequenzen oder RunableEntities, die durch eine externe Kommunikation oder global, d.h. bei einem gleichen Zeitintervall von TimingEvents, getriggert werden, werden hierbei zusammengefasst . Dies bedeutet, dass Ereignisse, welche innerhalb der zu erstellenden modifizierten Software-Komponente ablaufen, nicht nach außen sichtbar werden .
5. Ferner werden alle zusammenfassbaren Codesequenzen (RunableEntities) der zu verschmelzenden Software-Komponenten
(AtomicSoftwareComponentType) zu einer Codesequenz zu- sammengefasst . Codesequenzen sind hierbei verschmelzbar, wenn sie der Kategorie 1 angehören und dieselbe Aktivierungsperiode aufweisen. Kategorie 1 bedeutet, dass eine Codesequenz einen unterbrechungsfreien Ablauf erfordert. Formulierte Beschränkungen (Constrains) werden auf die Ausführungsreihenfolge der RunableEntities bei der Verschmelzung beachtet.
Durch das Modifikationsmittel 17 wird somit neben der modifizierten Komponentenbeschreibung 15 eine lokale Laufzeitum- gebung 16 („lokales_RTE (C)") erzeugt. Die Laufzeitumgebung 16 wird zusammen mit den modifizierten Implementierungsdaten 14 und den modifizierten Schnittstellendaten 13 zu einer modifizierten Software-Komponente verarbeitet. Das hierbei entstehende Ergebnis ist ein Objektfile 18, welches zusammen mit der modi- fizierten Komponentenbeschreibung 15 an die Partei B geliefert wird.
Die modifizierte Komponentenbeschreibung 15 wird hierbei einem Laufzeitumgebungserstellungsmittel („RTE-Generator") zuge- führt, welcher eine Schnittstellendatendatei 21 („h") sowie eine Implementierungsdatendatei 22, welche auch eine Laufzeitumgebung umfasst („C (RTE)") erstellt. Die Schnittstellendatendatei 21 sowie die Implementierungsdatendatei 22 werden zusammen mit der Objektdatei 18 einem Mittel 23 zur Erzeugung des Software-Systems zugeführt. Dies ist auch als „Build Process" bekannt .

Claims

Patentansprüche
1. Verfahren zum rechnergestützten Wissensschutz eines Software-Systems, insbesondere gemäß dem AUTOSAR-Standard, welches eine Mehrzahl an Software-Komponenten (1) mit jeweiligen
Software-Code umfasst, die zumindest teilweise an Schnittstellen
(3, 4) der Software-Komponenten (1) miteinander gekoppelt sind, wobei für jeweilige Software-Komponenten (1) und Schnittstellen
(3, 4) Komponentenbeschreibungen (12) vorgesehen sind, bei dem zumindest eine Teilmenge der Mehrzahl an Software-Komponenten
(1) zu einer modifizierten Software-Komponente (18) verarbeitet wird, wobei für die modifizierte Software-Komponente (18) und die
Schnittstellen (4) der modifizierten Software-Komponenten (18) zu den übrigen Software-Komponenten (1) jeweils modifizierte Komponentenbeschreibungen (15) erstellt werden.
2. Verfahren nach Anspruch 1, bei dem der Softwarecode der Teilmenge der Mehrzahl an Software-Komponenten (1) zu einem modifizierten Softwarecode verarbeitet wird.
3. Verfahren nach Anspruch 1 oder 2, bei dem für die modifizierte Software-Komponente (18) eine modifizierte Laufzeitumgebung (RTE) erstellt wird.
4. Verfahren nach einem der vorherigen Ansprüche, bei dem die modifizierte Laufzeitumgebung mit der modifizierten Software-Komponente (18) in ein binäres Objektformat überführt wird.
5. Verfahren nach einem der vorherigen Ansprüche, bei dem die Software-Komponenten (1), die zu einer modifizierten Software-Komponente (18) verarbeitet werden, auf dasselbe Steuergerät abgebildet werden.
6. Verfahren nach einem der vorherigen Ansprüche, bei dem der Softwarecode einer jeweiligen Software-Komponente (1) Implementierungsdaten (11) und Schnittstellendaten (10) umfasst, wobei die Softwarecodes der Teilmenge der Mehrzahl an Software-Komponenten (1) zu einem modifizierten Softwarecode ver- arbeitet werden, indem die jeweiligen Implementierungsdaten (11) der Software-Komponenten (1) zu einer modifizierten Implementierungsdatendatei (14) und die jeweiligen Schnittstellendaten (10) der Software-Komponenten zu einer modifizierten Schnittstellendatendatei (13) verarbeitet werden.
7. Verfahren nach einem der vorherigen Ansprüche, bei dem für alle Schnittstellen (3, 4) der Software-Komponenten beim Verarbeiten Codesegemente gemäß einer Spezifikation der Laufzeitumgebung erstellt werden.
8. Verfahren nach einem der vorherigen Ansprüche, bei dem für Laufzeitumgebungsereignisse, die innerhalb der modifizierten Software-Komponente (18) ablaufen, ein lokaler Laufzeitumge- bungscode erzeugt wird.
9. Verfahren nach einem der vorherigen Ansprüche, bei dem Hierarchien von Kompositionen (6), umfassend eine Mehrzahl an Software-Komponenten (1), aufgelöst werden.
10. Verfahren nach einem der vorherigen Ansprüche, bei dem gleichartige Laufzeitumgebungsereignisse, die durch ein außerhalb der modifizierten Software-Komponente (18) ablaufendes Ereignis getriggert werden oder die global getriggert werden, in der modifizierten Software-Komponente (18) zusammengefasst werden .
11. Verfahren nach einem der vorherigen Ansprüche, bei dem alle zusammenfassbaren Codesequenzen der Software-Komponenten (1), die in der modifizierten Software-Komponente (18) zusammenfassbar sind, in der modifizierten Software-Komponente zusammengefasst werden.
12. Verfahren nach Anspruch 11, bei dem Codesequenzen zusam- menfassbar sind, wenn diese der Kategorie 1 angehören und dieselbe Aktivierungsperiode haben.
13. Verfahren nach Anspruch 11 oder 12, bei dem formulierte Beschränkungen auf die Ausführungsreihenfolge der Codesequenzen bei der Verschmelzung berücksichtigt werden.
14. Computerprogrammprodukt, das direkt in den internen Speicher eines digitalen Computers geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß einem der Ansprüche 1 bis 13 ausgeführt werden, wenn das Produkt auf einem Computer läuft.
PCT/EP2008/055380 2007-05-15 2008-04-30 Verfahren zum rechnergestützten wissensschutz eines software-systems WO2008138770A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102007022708 2007-05-15
DE102007022708.8 2007-05-15

Publications (1)

Publication Number Publication Date
WO2008138770A1 true WO2008138770A1 (de) 2008-11-20

Family

ID=39737572

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/055380 WO2008138770A1 (de) 2007-05-15 2008-04-30 Verfahren zum rechnergestützten wissensschutz eines software-systems

Country Status (1)

Country Link
WO (1) WO2008138770A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102385530A (zh) * 2011-08-11 2012-03-21 浙江大学 一种应用于rte代码生成的os资源分配冲突解决方法
US20120159436A1 (en) * 2010-12-21 2012-06-21 Gary Morgan Method of bypassing an autosar software component of an autosar software system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006100078A1 (de) * 2005-03-24 2006-09-28 Dspace Digital Signal Processing And Control Engineering Gmbh Vergleich von schnittstellen zwischen softwarekomponenten

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006100078A1 (de) * 2005-03-24 2006-09-28 Dspace Digital Signal Processing And Control Engineering Gmbh Vergleich von schnittstellen zwischen softwarekomponenten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HEINECKE H ET AL: "AUTOSAR - Current results and preparations for exploitation", INTERNET CITATION, 3 May 2006 (2006-05-03), XP002466416, Retrieved from the Internet <URL:http://www.autosar.org/download/AUTOSAR_Euroforum_2006.pdf> [retrieved on 20080128] *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120159436A1 (en) * 2010-12-21 2012-06-21 Gary Morgan Method of bypassing an autosar software component of an autosar software system
US8966443B2 (en) * 2010-12-21 2015-02-24 Robert Bosch Gmbh Method of bypassing an AUTOSAR software component of an AUTOSAR software system
CN102385530A (zh) * 2011-08-11 2012-03-21 浙江大学 一种应用于rte代码生成的os资源分配冲突解决方法
CN102385530B (zh) * 2011-08-11 2013-09-25 浙江大学 一种应用于rte代码生成的os资源分配冲突解决方法

Similar Documents

Publication Publication Date Title
EP0825524A1 (de) Verfahren zur Verwaltung der Benennung von Objekten
EP1662381A1 (de) Engineeringsystem mit automatischer Generierung von Instanzvorlagen
DE102006035890A1 (de) System und Verfahren zur automatischen Installation und Wartung von Hard- und Software in einem verteilten Computersystem
EP1674954A1 (de) System und Verfahren zur Wiederverwendung von Projektierungsdaten
DE102011107646A1 (de) Verfahren und System zur dynamischen Verteilung von Programmfunktionen in verteilten Steuerungssystemen
WO2008138770A1 (de) Verfahren zum rechnergestützten wissensschutz eines software-systems
DE102017212581A1 (de) Verfahren zur dynamischen Erweiterung einer domänenspezifischen Sprache eines graphischen Modellierungswerkzeugs
EP3855260A1 (de) Verfahren zur konfiguration und parametrierung von feldbusteilnehmern und engineeringsystem
EP1383061A2 (de) Verfahren und Konfigurator zur Erstellung eines Anlagenkonzepts aus einer Anzahl von Anlagenkomponenten
DE102008023873A1 (de) Verfahren zum Betrieb eines Antriebssystems
DE10318292B4 (de) Verfahren zur Parametrierung und Projektierung von Kommunikationsnetzwerken und Kommunikationsnetzwerk zur Implementierung eines solchen Verfahrens in der Automatisierungstechnik
WO2021047970A1 (de) Software-komponenten für eine software-architektur
EP4010765A1 (de) System und verfahren zum bereitstellen einer digitalen nachbildung einer anlage und entsprechendes computerprogrammprodukt
EP1516234A2 (de) Informationserzeugungssystem für die produktentstehung
EP3890276A1 (de) Integrieren einer maschine in ein bestehendes distributed-ledger-netzwerk
EP2093663A1 (de) Engineering-System für die Entwicklung eines Projektes und Verfahren
DE102010061733B4 (de) Verfahren zum Erstellen eines Steuerprogramms
EP2126643A1 (de) Verfahren zum austausch von strukturkomponenten für ein automatisierungssystem
EP3620869A1 (de) Verfahren und umsetzungskomponente für den datenaustausch zwischen zwei systemen mit verschiedenen sicherheitskonzepten für funktionale sicherheit
EP3179364B1 (de) Verfahren und vorrichtung zur entwicklung von software eines steuerungs-/regelungssystems eines fahrzeuges
WO2004053739A2 (de) System zur generierung von automatisierungscode
DE102007049958A1 (de) Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation
DE10065286B4 (de) Verfahren zum Entwurf und/oder zum Betrieb kombinierbarer Komponenten (TYCS)
EP2010974B1 (de) Engineeringsystem und verfahren zur projektierung eines automatisierungssystems
DE10105729C1 (de) Verfahren und System zur funktionsmäßigen Erweiterung einer Telekommunikationsanlage

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: 08749956

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: 08749956

Country of ref document: EP

Kind code of ref document: A1