WO2019211122A1 - Feature-development-framework und feature-integration-framework zum implementieren physikalischer funktionsfeatures in einem zielgerät - Google Patents

Feature-development-framework und feature-integration-framework zum implementieren physikalischer funktionsfeatures in einem zielgerät Download PDF

Info

Publication number
WO2019211122A1
WO2019211122A1 PCT/EP2019/060333 EP2019060333W WO2019211122A1 WO 2019211122 A1 WO2019211122 A1 WO 2019211122A1 EP 2019060333 W EP2019060333 W EP 2019060333W WO 2019211122 A1 WO2019211122 A1 WO 2019211122A1
Authority
WO
WIPO (PCT)
Prior art keywords
feature
target device
features
software
user
Prior art date
Application number
PCT/EP2019/060333
Other languages
English (en)
French (fr)
Inventor
Andreas Lapp
Udo Schulz
Micha Muenzenmay
Mouham Tanimou
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 WO2019211122A1 publication Critical patent/WO2019211122A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • 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
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • 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/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/01—Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
    • G06N5/013—Automatic theorem proving

Definitions

  • Feature development framework and feature integration framework for implementing physical feature features in a target device
  • the invention relates to a feature development framework and a feature integration framework for the subsequent implementation or modification of physical function features in a target device, in particular a
  • Motor vehicle or a work or machine tool It also relates to a computerized method for creating such a feature development framework.
  • a functional feature to be implemented can be downloaded, for example, at any location where the motor vehicle is located, through a protected connection to a predetermined IT infrastructure (cloud) remote from the motor vehicle.
  • IT infrastructure cloud
  • Connection devices or over-the-air interfaces may be provided.
  • a security gateway is often present in the motor vehicle to break into the
  • Such new or updated physical function features can be designed and tested by the manufacturer, for example, in a known modeling environment, taking into account interfaces present in the motor vehicle and other functional components, and presented to the user or end user in the motor vehicle in the form of a
  • a feature development framework for the user-side development of physical functional features of a target device, in particular of a motor vehicle or a working or machine tool.
  • the feature development framework includes a
  • a computer-aided, in particular cloud-computing-based environment (also referred to as a feature development platform), comprising a feature developer software and access mechanisms controlled by the latter on hardware resources in the target device and in a remote IT environment.
  • Infrastructure also referred to as cloud
  • the feature developer software provides a user (also referred to as developer) for at least one physical function feature that can be implemented in the target device at least one predetermined design intervention point for its respectively qualitatively different design.
  • Design possibilities of the at least one functional feature on the target device of at least one predetermined technical requirement are. This makes it possible, in particular, to ensure that the customer / user of the feature development framework is provided only technically and legally (eg with regard to the approval of the target device) with unobjectionable intervention possibilities in feature development in the feature development platform are.
  • Physical feature features (also referred to herein as feature features or features) of a target device herein can be any target device controller (i.e., a target device controller) implementable and controllable by the target device, particularly a user or end user in the target device
  • Perceptible or verifiable technical specifications of (partial functions of the target device, such as individual functions of the engine control or cruise control or turbocharger functionality in a motor vehicle or individual functions of a camera-based plant detection and the dependent tool control on an agricultural machine such as combine harvester, etc .
  • a predetermined design intervention site provided to the user by the feature developer software may in particular define an interface in the destination control device that is designed to access an associated component of the target device, for example a turbocharger or a fresh air valve of a motor vehicle, for example in accordance with FIG the user-defined feature definition to change the control of this device or read its current state.
  • the IT infrastructure remote from the target device may be, in particular, a particular one, such as the Manufacturers of the Feature Development framework negotiate specified and / or controlled IT infrastructure that is used for communication and for
  • Data exchange with the feature development framework on the one hand and with the user and / or end user of the feature development framework and / or with a destination control device (in particular via a protected connection and / or from different places where he / she is located) on the other side is formed.
  • the at least one predetermined design intervention site may, for example, be provided to the user of the feature development platform at a cloud-based design or modeling level of the feature feature, i. H. even before the function feature is converted into a software code, compiled or integrated in the target controller.
  • the qualitatively different feature design at the predetermined design intervention points can in particular mean a modification of a standard feature provided by the manufacturer beyond purely quantitative parameter adjustments. This may, for example, the addition of further technical operating parameters (hereinafter also referred to as action and target parameters) of the target device, such. As a speed or an opening cross section of a component, etc., and / or a change or addition of a logical and / or physical
  • Dependency principles include such operating parameters with each other in the feature definition.
  • development herein includes, in addition to the development of new physical functional features, a modification or Update in the target device already implemented physical
  • the compliance implemented in the feature development framework by technical means (such as by a preceding and / or development process-accompanying check by simulating technical processes in the target device or by a specific usage or access control with regard to its hardware resources) the at least one predetermined technical requirement with respect to the feature integration in the target device always automatically sure that the user-customized
  • a feature development framework of the type set forth herein may not provide the user with a largely independent of the manufacturer, in particular outwardly, physical feature features set forth by the manufacturer
  • the feature development platform can for example represent a comparatively simple, handy and in terms of freedom of design particularly flexible software tool for the user, in which he in a technically and legally automatically secured way his own, to a specific area of application individually custom physical feature features for a target device or target device class.
  • the user-side feature design set forth herein may be used in the feature development platform using a common
  • Modeling environment such as B. Matlab / Simulink, be realized.
  • the user may have several, for example two, three, four or more, different ones for at least one function feature
  • the at least one predetermined technical requirement comprises one or more of the following requirements:
  • Target device whereby, for example, the mutual influence and the interaction of different physical function features can be considered in a functional network of the target device
  • Compliance with predetermined resource requirements for the hardware and software in the target device which may include, for example, a required for the implementation of a new or changed feature features equipment of the target device with specific devices, sensors or IT hardware resources of the target control device;
  • core herein stands for processor core.
  • At least one of the feature features that can be configured by means of the feature developer software represents an action chain of active relationships between active functions and target parameters relevant to the at least one predetermined design intervention point.
  • at least one can the function features that can be configured by means of the feature developer software comprise at least one operative context within such an action chain that can be modified at the at least one predetermined design intervention point. In this way, modifiable
  • Monitoring before, during or after implementation in the target device can be abstractly modeled.
  • an action chain is a sequence of interactions
  • Target parameter of an action parameter (where such a
  • a target parameter is a physical quantity having a desired value for performing a function in the target device, which may depend on one or more different effective parameters;
  • An action parameter is a physical quantity with a causal effect on a target parameter.
  • Branches may have, or be one or more interactions within an action chain.
  • the modification may include in particular:
  • boundary conditions can be defined, for example, as follows:
  • active and target parameters can in particular represent input and output variables for the respective function feature or its individual operative connection.
  • Examples of effect or target parameters are z. As speed, speed, opening area, temperature, etc. one
  • At least one of the physical function features that can be configured in the feature developer software is based on a formalized feature function in the feature developer software Chain of action description, z. B. a constraint graph defined or described. It is important to have a clear description of the chain of action and the allowed changes to this chain of action by means of a formalized methodology and a suitable computer-aided tool (hereafter: formalized chain of effects description) to ensure that the user only permitted modifications of the chain of action to the design specifically provided for this purpose Intervention points are available.
  • a constraint graph is merely one of the fundamentally arbitrary possible ways of defining physical function features and their predetermined design intervention points in the feature developer software.
  • the feature developer software includes simulation software for
  • the feature development platform includes one or more of the following entities:
  • At least one designed by the feature developer software physical function features is formed by the user such feature features and their respective predetermined design intervention points are available and / or selection made;
  • a feature development kit which prepares the at least one user-designed, in particular in the feature-preparator, functional features depending on the respective target device and / or for its optimization in terms of hardware resource utilization, effectiveness and / or time utilization the later implementation in the target device and / or for its testing for compliance with at least one of the predetermined technical requirements is formed;
  • the feature-preparator and / or the feature development kit designed feature features on its implementation in each target device and / or to optimize it in terms of hardware resource utilization, effectiveness and / or time utilization in the target device and / or for its examination Compliance is formed at least one of the predetermined technical requirements;
  • designing a feature feature in the feature preparator by the user may be user-selected
  • editing a user-created feature feature in the Feature Development Kit may include creating a software code (computer program or software package) that corresponds to the designed feature model and compiling, linking, and / or locating it for the target controller.
  • locating refers to assigning specific parts of a computer program, so-called program segments, to specific memory areas of a destination controller memory.
  • the user can in particular with useful, z.
  • it may provide its decision-making in facilitating custom feature design information about the design options available to the user, which may range from the technical implications of each selectable design interface of the feature to the target device, to the licensing issues that may be involved ,
  • the feature development framework further includes an end-user front-end (referred to herein as a feature store) that includes end-user feature acquisition software that is capable of finding and downloading the at least one by means of the feature development tool.
  • a feature store includes end-user feature acquisition software that is capable of finding and downloading the at least one by means of the feature development tool.
  • Platform is designed individually for a particular scope of user-designed / developed functional features for the target device.
  • the feature store is controlled by this acquisition software Access mechanisms on hardware resources in the target device and in the IT infrastructure remote from it.
  • the end user may (but does not have to) be a different person than the user (also referred to herein as a developer) who subscribes to the at least one feature feature offered for download in the feature store
  • the end user may be a keeper or driver of a
  • Haulage company hired engineer, on-board electronics, technical or safety officer.
  • the finding of the feature features to be offered in the feature store by the end user can be facilitated in particular by the provision of graphical feature feature identification elements such as icons and / or interactive graphical user interfaces (GUI).
  • GUI graphical user interfaces
  • Compatibility check to be implemented with the specific software and hardware equipment of the specific target device. This can be achieved through access to hardware resources controlled by the acquisition software in the target device and in the IT infrastructure remote from it.
  • a method for creating a feature development framework of the type set forth herein, in which the at least one predetermined design intervention point is designed for the at least one physical function feature that can be implemented in the target device and can be configured by the feature developer software , checked and then provided
  • Functional feature causes its implementation in the target device, and their interactions with other physical functional features in the target device and / or with the hardware resources of the target device and / or the remote IT infrastructure are simulated, in particular with computer-aided means such.
  • a common simulation environment such as Matlab / Simulink,
  • a computer program which, when executed in a control device or a data processing device, is arranged to execute such a method.
  • a feature integration framework for integrating user-customized physical design by means of the feature development framework of the type set forth herein
  • Target device (hereinafter abbreviated: target control device) can be installed, in particular, but not necessarily next to a master core on which one
  • Operating system of the target controller is running, at least one other core with it running virtual machines for other software applications may have, and
  • the feature integration framework includes one or more of the following components:
  • a virtual machine interface adapted to access on the side of a master software running on the master core
  • At least one virtual machine adapter each of which is designed as a counterpart of the virtual machine interface on each of the virtual machines to function calls one on the respective virtual
  • a feature coordinator-on-device which is designed to coordinate each integrated or already integrated individually designed physical function feature with the other hardware and software resources of the target device, in particular to schedule, start and / or stop these feature features ,
  • This feature integration framework is designed to install new or changed functional features in the target control device, which are not rigidly predetermined by the manufacturer in advance, but qualitatively vendor-independent of a user, for example by means of a feature Development frameworks of the kind set forth herein.
  • the feature integration framework thus enables hosting of the type set forth herein by means of the feature development framework user - specific, individually designed physical function features in the
  • Target controller As a result, in particular a controlled and flawless execution of these function features by the target control device and thus their implementation in the target device can be made possible.
  • the feature integration framework or its individual components such as the feature proxy-on-device and / or feature coordinator-on-device may be designed to communicate with the feature development framework of the type set forth herein, For example, to exchange information or software or to pass calls to perform a test and / or simulation.
  • This can in particular serve a data exchange and / or a hardware comparison with respect to the function features individually designed via the feature development platform, eg. B. for the purpose of hardware and software compatibility control with the target device and its functional network and / or monitoring to ensure proper functioning of this newly integrated
  • the feature proxy-on-device is further thereto designed to monitor at least some interactions of the integrally designed or already integrated individually designed physical function features, preferably their duration. This can be done in particular by modeling implemented in the feature proxy-on-device and / or
  • the feature coordinator-on-device is designed for the same purpose, at least some of the individually designed to be integrated or already integrated
  • Such substitute values can also be substitute variables with several different situation-dependent predetermined values.
  • Feature-Preparator the Feature-Development-Checker
  • Feature-Development-Kit the special suitable simulation software implemented in it.
  • the controller has a feature integration framework of the type set forth herein.
  • this may be the target controller mentioned elsewhere herein.
  • the control unit may have at least one further core with virtual machines running thereon for further software applications.
  • a machine-readable storage medium is provided on which a feature development framework and / or a
  • Figure 1 is a schematic overview of a
  • Figure 2 is a schematic overview of an exemplary
  • Figure 3 is a schematic overview of an exemplary
  • Figure 4 and 5 possible representation of in a feature development platform of the kind set forth herein individually configurable physical function features in the form of predetermined design intervention points of modifiable chains of action;
  • Figure 6 is an example of the description of the modifiable chain of action of Figure 5 through a formalized chain of effects description, e.g. By means of a constraint graph;
  • Figure 7 is an illustrative representation of the feature development steps of Figure 3 in a feature development platform of the type set forth herein;
  • FIG. 8 shows a detailed representation in the feature development platform of FIGS. 3 and 7 of implemented simulation and test steps
  • Figure 9 is a schematic representation of an example of the software architecture of a feature integration framework installed in a target controller of the type set forth herein;
  • FIG. 10 shows the feature integration framework of FIG. 9 separately;
  • Figure 1 1 is a schematic block diagram of an example in a
  • Figure 12 is a schematic block diagram of an example in one
  • FIG. 13 is a schematic diagram of one generated in a feature coordinator on device of the type set forth herein for monitoring a newly designed one
  • Figure 14 is a schematic block diagram of a
  • Figure 1 illustrates an example of possible IT components for a cloud-based user, i. H. customer individual design of physical
  • Figure 1 shows a schematic Overview of the following formed for mutual communication elements: a feature development framework 1 of the kind set forth herein, one installed in a controller 2 of a target device 3 (short: destination control device 2) feature integration framework 4 of the type set forth herein and one of the target device. 3 remote IT infrastructure 5 (cloud, such as Bosch-loT-Cloud & Services or BIC).
  • cloud such as Bosch-loT-Cloud & Services or BIC
  • the target device 3 represents by way of example only a motor vehicle, which may in particular be a commercial vehicle.
  • a security gateway (not shown) may be provided to break into this In addition to complicate over-the-air interfaces.
  • the feature development framework 1 has one
  • Feature development platform 1 a which for the individual, ie qualitatively different design of physical features for the target device 3 by a user 10 (shown in FIGS. 2 and 3) is formed.
  • This can be, for example, the addition of further technical operating parameters (eg as effective and target parameters in the impact chain definition of a functional feature described above and also with reference to FIGS.
  • development herein includes, in addition to the development of new physical functional features, a modification or
  • the feature development framework 1 in the embodiment according to FIG. 1 comprises a feature store 1b with feature acquisition software (not shown) for locating and downloading the feature features developed by the feature development platform 1a by an end user 11 (shown in Figs. 2 and 3).
  • the feature store 1b represents an end-user front-end to find and select needed new feature features. Furthermore, it can the
  • the feature store 1b can be designed, for example, to be coupled to a FOTA infrastructure (firmware update-over-the-air) and / or a SOTA infrastructure (software update-over-the-air) in order to be automatic to select a correct version of a firmware or functional feature for a specific target device 3 or its target controller 2.
  • the feature store 1 b in particular also be adapted to the correct and correct
  • the feature development platform 1 a provides the user 10 an environment with which a required feature feature can be customized.
  • the feature-preparator 6 the feature-development-kit 7, the feature-deployment-checker 8 and a brokering-platform 9.
  • the brokering-platform 9 is to incorporate user support regarding relevant engineering services such as device management, etc.
  • sub-unit 9a licensing (sub-unit 9b), and other consulting (sub-unit 9c) into the feature development process, and may therefore be used in feature development Platform 1 a may be implemented either independently or together with one or more of the other three units. The possible interaction between these three units and their respective properties will be explained in more detail below with reference to FIG.
  • FIG. 3 shows a schematic overview of a possible sequence of steps from the individual feature design by a user 10 of a feature development framework 1 of the kind set forth herein to the selection and implementation of such an individually designed functional feature in a target device 3 by an end user 11, z.
  • FIG. 3 firstly describes a possible embodiment of the feature-preparator 6 of the feature development platform 1a.
  • the feature-preparator 6 is designed for the user-side designing of physical function features by providing the user 10 with at least one such function feature,
  • predetermined design intervention points each to a permissible individual feature modification provides.
  • the feature development in the feature development platform 1a in particular the manufacturer-side creation of the standard features with the predetermined design intervention points and / or the individual feature design by the user 10 in the feature-preparator 6, for example, with
  • step Q3 further information relevant to the development of a feature model about the software architecture present in the target device 3 can be provided, for example in the form of a "data-dictionary". In it can relevant
  • Equipment data in particular on existing in the target device 3 functional components, as well as messages and / or variables that may be changed by the new feature features to be included.
  • messages means a communication variable between software components, wherein messages can be characterized by physical units, quantization, value ranges and / or update frequency.
  • an action chain is a sequence of interactions
  • Target parameter of an action parameter (where such a
  • a target parameter is a physical quantity having a desired value for fulfilling a function in the target device 3, which may depend on one or more different effective parameters;
  • An action parameter is a physical quantity with a causal effect on a target parameter.
  • a physical function feature which can be designed by means of the feature development platform 1a can therefore in particular:
  • the modification of an existing chain of action in the destination control device 2, or the user 10 allowed to modify a manufacturer-provided standard features at the predetermined design intervention points in the feature development platform 1 a may include in particular:
  • boundary conditions can be defined, for example, as follows:
  • Position_WZH_N Position_WZH_K + 1 or
  • Target device 3 may be implemented in the feature-preparator 6, the testing of predetermined technical requirements of the type shown herein, z. B. with respect to specific
  • z. B. can in a motor vehicle, which is equipped because of the automatic emergency braking with a front-mounted radar, the ACC (Adaptive Cruise Control) are subsequently downloaded.
  • ACC Adaptive Cruise Control
  • each rectangle S1, S12, S2, S2 ', S3... Characterizes in the most general sense a subsystem which may contain a single or multiple operative connections.
  • allowed i.e., the user 10 in Feature Preparator 6 made available
  • the knitting chains W1, W2, W3, W4 and W5 in FIGS. 4 to 6 can not be modified by the user 10 on their parts indicated by solid lines.
  • action and target parameters can represent, in particular, input and output variables for an action chain or their individual interaction.
  • effect and target parameters are z.
  • a plurality of such chains of action eg torque chain of action, air supply chain of action, etc.
  • their interaction can be defined by means of the feature development platform 1 a, which are later to be implemented by a control device software ,
  • the latter can z.
  • Modifications can be z.
  • Example based on constraint graphs are described (see Fig. 6).
  • the constraint graphs are extended with attributes that characterize the allowed modifications.
  • the sum of these attributes defines the degrees of freedom for the possible optimization of the entire chains of effects, eg. B. in terms of hardware resource utilization and / or effectiveness and / or time utilization in the implementation of the function chain defined by the functional feature feature in the target device 3.
  • Wirkzusammenhow be in an action chain in the feature development platform 1 a, in particular in the feature-Preparator 6, implemented.
  • Such optimization of the chain of action and / or its testing for compliance with at least one of the predetermined technical requirements of the kind set forth herein can be done both in the feature-preparator 6 and in other units of the feature development platform 1a in further steps Q6 (optimization) and Q7-Q8 (check) of FIG. 3 may be implemented in the context of a simulation Q5 of the feature.
  • it can be determined with regard to a MultiCore system in the target control unit 2, which Functional features (chains of action or parts thereof) can be parallelized in order to obtain full performance with regard to core balancing.
  • Target controller 2 defined in advance and / or taken into account in the feature optimization.
  • 5 and 6 show an example of the definition of an action chain W5 with the user 10 allowed modifications by a formalized
  • Active chain description. 5 and 6 each show, for comparison purposes, a standard rigid action chain W4 which is rigidly fixed by the manufacturer and consists of three successive subsystems S1, S2 and S3 (which may be, for example, individual operative connections) which can not be modified by the user.
  • the action chain W5 provided in the feature development platform 1a can be interspersed by the user 10 at their elements shown in dashed lines in FIG.
  • Subsystems S1 and S3 are designed individually.
  • the modifications of the action chain W5 permitted at these design intervention points are defined by means of the formalized chain of effects description according to FIG.
  • the XOR gate links contained therein indicate that the optional subsystem S2 'is an "either or” alternative to the subsystem S2, as well as the optional subsystem S23' permanently connected due to the AND gate to other subsystems S4 and S5. represents an "either or” alternative to the optional subsystem S23.
  • the OR gate specifies that the user 10 can freely decide on the addition of the optional subsystem S12 and one of the two alternatives S23 and S23'-S4-S5.
  • the software code for the functional feature is automatically generated and compiled, linked and located for a specific target control device 2 (such as vehicle management computer or VCU, vehicle control unit).
  • a specific target control device 2 such as vehicle management computer or VCU, vehicle control unit.
  • the developed function feature is simulated and tested in further, above-mentioned steps Q5 to Q8, for example, also in the feature development kit 7 or at least partially in the feature deployment checker. 8 can be implemented.
  • Simulating Q5 and testing Q7 can be multi-level, as illustrated symbolically in FIG. 8: in a first step Q57a, for example, by simulating the individual function feature alone can ensure that its implementation (at this point in the sense of the generated and for the simulation compiled code) corresponds to the predetermined requirements of the desired feature, eg. B. by a so-called MIL-SIL comparison for Model-In-The-Loop and Software-In-The-Loop. In a further step Q57b, it can be verified whether the correct insertion of the functional feature implemented in this way into the existing effective chains of the target device 3 has taken place. Other simulation tests Q57c in an even more comprehensive target device architecture can help ensure proper integration of the new feature feature into the existing functional network of the target device 3.
  • steps Q57b-Q57c the fulfillment of these and other of the predetermined technical requirements described herein can be checked and ensured in steps Q57b-Q57c.
  • the function feature in the above optimization step Q6 can be optimized so that the resources available in the target device 3 are handled as carefully as possible.
  • this check may be related to ensuring interference-freeness, i. H. mutual
  • Non-impairment of the functional features in the target device 3 be implemented. In particular, it can thus be ensured that function features which are not relevant for the homologation actually do not impair the type approval of the existing target device 3.
  • functional features that are, however, relevant to homologation eg with regard to emissions legislation for If necessary, prior to their implementation, a required type-approval must be made by means of an amendment to a suitable audit organization.
  • a feature feature designed in the feature development platform 1 a In order for a feature feature designed in the feature development platform 1 a to be found and selected by the end user 11 in the feature store 1 b and to be operable by a terminal device such as a head-unit display, a tablet 17 or a smartphone 18
  • a terminal device such as a head-unit display, a tablet 17 or a smartphone 18
  • graphical elements such as "icons” or graphical user interfaces (GUI) for functional features to be offered can be provided.
  • GUI graphical user interfaces
  • a billing model can be provided for payment of the item to be offered
  • the feature development steps described above with reference to FIGS. 3 to 6 in the feature development platform 1 a are from the manufacturer and user-side feature modeling Q 1 with the manufacturer side
  • FIG. 7 shows, in particular, the manufacturer or provider-side provision of the target device interfaces 12, the effective chain modifications permitted by the formalized chain description, and the standard effect chains 14 dependent thereon (manufacturer-side feature model) with predetermined design intervention points for the user 10 schematically illustrates. Furthermore, a user model 10 of FIG. 3 from this individually designed feature model 15 and a manufacturer provided simulation model 16 of the remaining target ECU equipment for simulating the designed by the user 10 function features are schematically indicated. Feature models 14 and 15 Here, A and B can in particular input parameters as well as C and D
  • FIG. 9 illustrates in a schematic representation an example of the software architecture of such a feature integration framework 4 in one
  • Figure 10 shows the feature integration framework 4 of Figure 9 again separately.
  • the feature integration framework 4 of FIG. 9 is designed to provide the action parameters of the target device 3 selected by the user 10 in the feature preparator 6 of the feature development platform 1a of FIG. 1, for example, and to set the target parameters of the target device 3 in accordance with FIG. 1
  • the feature integration framework 4 of FIGS. 9 and 10, by way of example only, comprises the following elements: a LightWeight hypervisor (LWHVR), a virtual machine interface (VMI), at least one virtual machine adapter (VMA), one
  • LWHVR LightWeight hypervisor
  • VMI virtual machine interface
  • VMA virtual machine adapter
  • Feature proxy-on-device and a feature coordinator-on-device (FCoD), which are described below individually and in their interaction with each other in the target control device 2 of FIG. 9.
  • FCoD feature coordinator-on-device
  • the feature integration framework may be a single or any combination of some of these four types of elements, such as: B. can be installed as retrofit software in the existing target control unit 2.
  • the exemplary functionalities and properties of these individual elements described below may also be partly different
  • subsequently loaded functional features can in particular be automatically ensured that the remaining functionality of the target device 3 is not impaired.
  • LWHVR LightWeight hypervisor
  • the concept for using the LWHVR can in particular be that on a master core (Core 0) of the target control device 2, an operating system (OS), such. As RTA OS, as well as important for the operation of master software, such. B. AUTOSAR and other security-related software, run.
  • OS operating system
  • On other cores in general any number: Corel to Core n; in Fig. 9: Core 1, Core 2 and Core 3) run independently of each other in terms of runtime, memory access, etc. independent other software applications (also as Guest-S oftware within one or more virtual machines (generally any number: VM1 to VMx; in Figure 9: VM1, ... VMm, ... VMy).
  • the Master Software and the Virtual Machines may only communicated via the so-called shared memory; accordingly, they can not call each other's functions nor access each other's variables.
  • the virtual machine interface (VMI) of the kind set forth herein is designed to bridge this on the master software side (see Fig. 9) so as to reside on the virtual machines (VM1, ... VMm,. .. VMy) running novel feature features access to without the VMI only the master software accessible information such.
  • the VMI is configured to provide or perform controlled access for guest software running on the virtual machines to a periphery of the system via the master software.
  • a function feature subsequently loaded as a guest software can be used to access the effective and target parameters of the target device 3, which otherwise would only be accessible to the master software.
  • VMA virtual machine adapter
  • the feature proxy-on-device is adapted to intervention points (target and action parameters) in the target device 3 in the technically and legally permissible, for example by means of the feature-preparator 6 of the feature development platform 1 a of FIG. To provide 1 individually designed impact chains.
  • the FPoD forms a kind of bypass functionality in the master software, as illustrated in FIG. 11.
  • 1 1 shows in a schematic block diagram an example implementation steps implemented in the FPoD for a new function feature of FIG. 11.
  • a call for reading out and / or changing a target or effective parameter of the target device 3 according to the definition of the new function feature is obtained, for example from the VMI.
  • an approval step Q12 it is checked whether the new function feature or the resulting target or effect parameter change is permissible.
  • a step Q16 for example, it provides a parameter value calculated by the function feature.
  • a symbolic switch 19 into the corresponding lower strand (not shown, i.e. the logic gate of Fig. 11 is shown in its rest position).
  • the provided parameter value can be used according to the feature definition for changing the effect or target parameters in the target device 3. If the switch 19 is not active (rest position as shown in FIG. 11), d. H. switched to the upper strand, according to the call received in step Q11, for example, in step Q14, a parameter value may be supplied from the master software, which is then used in step Q15 in the target device 3.
  • the technical and legal permissibility of a functional feature to be integrated in the functional composite of the target device 3 via the FPoD in the functional grouping of the target device 3 can be checked, for example, in the above approval step Q12. B. in the fulfillment of at least one of the predetermined technical requirements of the type set forth herein. A corresponding check can be implemented in particular in the FPoD itself.
  • the FPoD can additionally be designed to be central or
  • the FPoD can be designed, for example, to have the feature behavior defined in the feature-preparator 6 of FIG. For example, to model by constraint graphs and / or to use such a model to monitor the interaction of the newly integrated function features. In this way, for example, the non-violation of predetermined permissible ranges of values within chains of action or also an expected basic behavior between the affected effect and target parameters can be checked by the FPoD or monitored during runtime of the feature.
  • the feature coordinator-on-device may represent one of the central elements of the feature integration framework 4 of the type set forth herein.
  • it can be automatically generated in the target controller 2 on the basis of the interfaces used in the target device 3 by the function features as well as the dependencies between the feature features.
  • the FCoD can be implemented to ensure, test and / or monitor the fulfillment of at least one of the predetermined technical requirements of the type set forth herein.
  • certain functional features can build on other functional features, such. B. that distance control requires cruise control.
  • distance control requires cruise control.
  • FIG. 12 shows a schematic block diagram of an example in a FCoD of the type set forth here of monitoring steps for a new functional feature of the target device 3 during the feature runtime.
  • a control step Q16 it is checked whether the functional feature and the virtual machine on which it is running, with respect to predetermined technical
  • a symbolic switch 20 is connected in its lower strand (this position is not shown in FIG. 12), whereby in an input step Q17 a current output value X of another functional feature required according to the feature definition is obtained from the virtual machine , The obtained output value X is used further in a further step Q18 according to the feature definition, e.g. B. forwarded to a corresponding change of an effective or target parameter of the target device 3 to the VMI. If, however, in the control step Q16 a failure of the other required
  • the switch 20 is connected in accordance with FIG. 12 in its upper strand, in which in a replacement step Q19 a suitable substitute value for the output value X is obtained and used in step Q18.
  • the FCoD can be designed to provide more abstract models of fan models (eg, by using a formalized chain description, eg, by means of a constraint graph, as in FIG. 6), for example, in Feature Preparator 6 of the feature model.
  • Development platform 1 a of Figure 1 selected and / or specified feature degrees of freedom to generate within chains of action. Using such shaker models, the FCoD can do so
  • FIG. 13 is a schematic diagram illustrating an example of such an observer model automatically generated in a FCoD of the kind set forth herein and used to monitor a redesigned one
  • Simulation model 16 of the remaining target ECU equipment can be used.
  • a and B may denote in particular input parameters as well as C and D output parameters of a chain of action or their individual operative relationships or else within operative relationships which are eg. B. above-described effect and target parameters of the respective feature features can be.
  • FCoD may be configured to schedule the functional features under its control (i.e.
  • FCoD Planning order of execution among each other), to start and / or to stop. Furthermore, the FCoD can be designed for a
  • FIG. 14 shows a possible block diagram in a schematic block diagram
  • the arrows indicate the direction of passing the effect and destination parameters between a virtual machine VMm, on which new functional feature 24 runs as guest software, and the master software (master SW) running on the master core (see FIG.
  • the VMI and the FPoD may be installed / installable in the software architecture of the target controller 2, particularly on the master software side, that is, as shown in FIG. H. in a privileged area 25 associated with the master core and the master software.
  • the feature development framework 1 and the destination control device 2 can be equipped by
  • predetermined design intervention sites allowable modifications described, which should be provided to the user 10 in the feature development platform 1a for individual feature design, that is to say:
  • ASIL Automotive Safety Integrity Level
  • Frameworks 4 is prepared so that more, especially newly designed feature features added and already implemented feature features can be changed in particular in a novel way, where
  • LWHVR LightWeight hypervisor
  • a Feature Coordinator-on-Device may be installed as a feature integration framework 4 to provide the allowed target and action parameters of the target device 3 for feature development.
  • Step I Access to the cloud-based feature development platform 1 a via a PC or a mobile terminal
  • the user 10 logs in via a terminal 26, in particular a smartphone or a PC, in the feature development framework 1 and thereby receives the feature development platform 1 a, ie a web user interface environment, provided, with whom he will be
  • desired function feature can customize.
  • Step II Development of a new functional feature using the feature development platform 1a
  • a model skeleton is built (a standard modifiable chain of action 14 of Figure 7 according to steps Q1, Q3 of Figure 3) in which the user 10 at the provided design intervention sites by allowed modifications of the standard chain of action 14 its incorporates individual functionality and thus receives a user-designed feature model 15 of FIG.
  • a software code is generated in step Q4 of FIGS. 3 and 7, which is then compiled and linked.
  • this software code can be simulated and tested in steps Q5-Q7 of FIGS. 3, 7 and 8, for example.
  • the possible (that is to say still remaining) predetermined by the user 10 may be provided.
  • Modifications / degrees of freedom in the chains of effects of the feature coordinator-on-device (FCoD) of Figures 9-14 are generated automatically in the target controller 2.
  • Step III Preparation of the developed functional feature on its
  • Memory requirements - RAM, Flash - real-time requirements, runtime requirements, jitter, latency, etc. are checked in the target controller 2.
  • Step IV Acquisition of the redesigned feature feature in the feature store 1 b by the end user 1 1
  • Step V Download the purchased function feature to the target controller 2
  • the selected function feature (eg, as a software package) to the target controller 2 or at the Installation of the functional feature trained unit, such as a
  • Target controller 2 makes.
  • CCU stands for a Connected Control Unit
  • CGW stands for a Central Gate Way, ie a control unit which has a connection to the Cloud 5.
  • Step VI Monitor the new one installed in the Target Controller 2
  • the functional feature is now installed in the target controller 2, and in particular it may be further communication between the target device 3, the remote IT infrastructure 5 (cloud) and the end user
  • an FCoD of FIG. 9-14 can be activated automatically, which can also be designed to monitor the started function feature, for example by B. ensures that even if parts of the function of the feature this still functional can continue, for example, with appropriate substitute values such. B. described with reference to FIG 12, is supplied.
  • a suitable observer model such as described with respect to FIG. 13, to ensure compliance with at least one of the predetermined technical requirements, which may be formed using constraint graphs, for example, and may ensure that predetermined limits or functional characteristics are determined

Abstract

Die Erfindung betrifft ein Feature-Development-Framework (1) zur benutzerseitigen Entwicklung physikalischer Funktionsfeatures eines Zielgeräts (3), insbesondere eines Kraftfahrzeugs oder einer Arbeits- oder Werkzeugmaschine, umfassend - eine computergestützte Umgebung (Feature-Development-Plattform 1a), die eine Feature-Entwickler-Software und von dieser gesteuerte Zugriffsmechanismen auf Hardware-Ressourcen im Zielgerät (3) und in einer von diesem entfernten IT-Infrastruktur (5) aufweist, - wobei die Feature-Entwickler-Software einem Benutzer (10) für mindestens ein im Zielgerät (3) implementierbares physikalisches Funktionsfeature mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle zu dessen jeweils qualitativ unterschiedlicher Gestaltung bereitstellt - und wobei die technischen Auswirkungen der durch die mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle bereitgestellten Gestaltungsmöglichkeiten des mindestens einen Funktionsfeatures auf das Zielgerät (3) mindestens einer vorbestimmten technischen Anforderung genügen.

Description

Beschreibung
Titel
Feature-Development-Framework und Feature-Inteqration-Framework zum Implementieren physikalischer Funktionsfeatures in einem Zielqerät
Technisches Gebiet
Die Erfindung betrifft ein Feature-Development-Framework und ein Feature- Integration-Framework zum nachträglichen Implementieren oder Modifizieren physikalischer Funktionsfeatures in einem Zielgerät, insbesondere einem
Kraftfahrzeug oder einer Arbeits- oder Werkzeugmaschine. Sie betrifft auch ein computergestütztes Verfahren zum Erstellen eines solchen Feature- Development-Frameworks.
Stand der Technik
Insbesondere für Kraftfahrzeuge sind Software-Aktualisierungen in einem an Bord befindlichen Steuergerät bekannt, die einem nachträglichen Ergänzen oder Aktualisieren für den Fahrzeugbetrieb wichtiger physikalischer Funktionsfeatures, die z. B. Einzelheiten einer Motorsteuerung oder Geschwindigkeitsregelung betreffen, dienen. Dabei kann ein zu implementierendes Funktionsfeature beispielsweise an einem beliebigen Ort, an dem sich das Kraftfahrzeug befindet, durch eine geschützte Verbindung zu einer vorbestimmten vom Kraftfahrzeug entfernten IT-Infrastruktur (Cloud) heruntergeladen werden. Hierzu können in Steuergeräten des Kraftfahrzeugs beispielsweise geeignete
Verbindungseinrichtungen oder Over-The-Air-Schnittstellen vorgesehen sein. Abhängig von seiner Elektrik/Elektronik-Architektur, wie der Partitionierung von Funktionen auf Steuergeräten und deren Vernetzung, ist im Kraftfahrzeug häufig auch ein Security-Gateway vorhanden, um einen Einbruch in die
Fahrzeugschnittstellen zusätzlich zu erschweren. Derartige neue oder aktualisierte physikalische Funktionsfeatures können beispielsweise in einer an sich bekannten Modellierungsumgebung unter Berücksichtigung im Kraftfahrzeug vorhandener Schnittstellen und anderer funktionaler Komponenten herstellerseitig entworfen und geprüft werden und dem Benutzer oder Endanwender im Kraftfahrzeug in Form eines zum
Herunterladen und Integrieren im fahrzeuginternen Steuergerät fertigen
Software-Codes bereitgestellt werden. Dabei stehen dem Benutzer oder Endanwender jedoch keine Instrumente zur Verfügung, das physikalische Funktionsfeature auf der Entwickler-Ebene und vor dessen Implementierung im Kraftfahrzeug selbst qualitativ unterschiedlich, d. h. individuell mitzugestalten.
Offenbarung der Erfindung
Erfindungsgemäß sind ein Feature-Development-Framework gemäß Anspruch 1 sowie ein Verfahren zu dessen Erstellung, ein entsprechendes
Computerprogramm, ein Feature-Integration-Framework, ein Steuergerät und ein maschinenlesbares Speichermedium gemäß den nebengeordneten Ansprüchen vorgesehen.
Weitere Ausführungsformen sind in den abhängigen Ansprüchen angegeben.
Alle in den Ansprüchen und der Beschreibung für das Feature-Development- Framework und das Feature-Integration-Framework genannten weiterführenden Merkmale und Wirkungen gelten auch in Bezug auf das Erstellungsverfahren und das Steuergerät, wie auch umgekehrt.
Gemäß einem ersten Aspekt ist ein Feature-Development-Framework zur benutzerseitigen Entwicklung physikalischer Funktionsfeatures eines Zielgeräts, insbesondere eines Kraftfahrzeugs oder einer Arbeits- oder Werkzeugmaschine, vorgesehen. Das Feature-Development-Framework umfasst eine
computergestützte, insbesondere auf Cloud-Computing basierte Umgebung (auch als Feature-Development-Plattform bezeichnet), die eine Feature- Entwickler-Software und von dieser gesteuerten Zugriffsmechanismen auf Hardware-Ressourcen im Zielgerät und in einer von diesem entfernten IT- Infrastruktur (auch als Cloud bezeichnet) aufweist. Die Feature-Entwickler- Software stellt einem Benutzer (auch als Entwickler bezeichnet) für mindestens ein im Zielgerät implementierbares physikalisches Funktionsfeature mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle zu dessen jeweils qualitativ unterschiedlicher Gestaltung bereit.
Dabei genügen die technischen Auswirkungen der durch die mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle bereitgestellten
Gestaltungsmöglichkeiten des mindestens einen Funktionsfeatures auf das Zielgerät mindestens einer vorbestimmten technischen Anforderung. Dadurch kann es insbesondere gewährleistet sein, dass dem Kunden/Benutzer des Feature-Development-Frameworks nur technisch und rechtlich (z. B. im Hinblick auf die Zulassung des Zielgeräts) unbedenkliche Eingriffsmöglichkeiten bei der Feature-Entwicklung in der Feature-Development-Plattform bereitgestellt sind.
Physikalische Funktionsfeatures (die hierin auch kurz als Funktionsfeatures oder Features bezeichnet werden) eines Zielgeräts können hierin beliebige den Betrieb des Zielgeräts beeinflussende, in einem Zielsteuergerät (d. h. einem Steuergerät des Zielgeräts) implementierbare und von diesem steuerbare, insbesondere von einem Benutzer oder Endanwender im Zielgerät
wahrnehmbare oder überprüfbare technische Spezifikationen von (Teil- Funktionen des Zielgeräts sein, wie z. B. Einzelfunktionen der Motorsteuerung oder der Geschwindigkeitsregelung oder der Turbolader-Funktionalität bei einem Kraftfahrzeug oder Einzelfunktionen einer kameragestützten Pflanzenerkennung und der davon abhängigen Werkzeugansteuerung bei einer landwirtschaftlichen Maschine wie Mähdrescher etc.. Eine von der Feature-Entwickler-Software dem Benutzer bereitgestellte vorbestimmte Gestaltungs-Eingriffsstelle kann insbesondere eine Schnittstelle im Zielsteuergerät definieren, die zum Zugreifen auf ein zugehöriges Bauelement des Zielgeräts, beispielsweise einen Turbolader oder ein Frischluftventil eines Kraftfahrzeugs, ausgebildet ist, beispielsweise um gemäß der vom Benutzer mitgestalteten Feature-Definition die Ansteuerung dieses Bauelements zu verändern oder dessen aktuellen Zustand auszulesen.
Bei der vom Zielgerät entfernten IT-Infrastruktur (hierin auch als Cloud bezeichnet) kann es sich insbesondere um eine bestimmte, beispielsweise vom Hersteller des Feature-Development-Frameworks festgelegte und/oder kontrollierte IT-Infrastruktur handeln, die zur Kommunikation und zum
Datenaustausch mit dem Feature-Development-Framework auf der einen Seite und mit dem Benutzer und/oder Endanwender des Feature-Development- Frameworks und/oder mit einem Zielsteuergerät (insbesondere über eine geschützte Verbindung und/oder von verschiedenen Orten, an denen er/es sich befindet) auf der anderen Seite ausgebildet ist.
Es ist eine Idee des obigen Feature-Development-Frameworks, einem
Benutzer/Entwickler auf der von dem Software-Hersteller zu unterscheidenden Kundenseite durch die mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle ein Instrument zur Verfügung zu stellen, physikalische Funktionsfeatures noch vor deren Download und/oder Implementierung im Zielgerät eigenhändig qualitativ unterschiedlich, d. h. individuell mitzugestalten. Die mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle kann dem Benutzer der Feature- Development-Plattform beispielsweise auf einer Cloud-basierten Entwurfs- oder Modellierungsebene des Funktionsfeatures bereitgestellt sein, d. h. noch bevor das Funktionsfeature in ein Software-Code umgewandelt, kompiliert oder im Zielsteuergerät integriert wird.
Die qualitativ unterschiedliche Feature-Gestaltung an den vorbestimmten Gestaltungs-Eingriffsstellen kann insbesondere eine über rein quantitative Parameteranpassungen hinausgehende Modifikation eines herstellerseitig bereitgestellten Standard-Features bedeuten. Dies kann beispielsweise das Hinzufügen weiterer technischer Betriebsparameter (hierin nachfolgend auch als Wirk- und Zielparameter bezeichnet) des Zielgeräts, wie z. B. einer Drehzahl oder eines Öffnungsquerschnitts eines Bauteils etc., und/oder eine Änderung oder Hinzufügung eines logischen und/oder physikalischen
Abhängigkeitsprinzips (hierin nachfolgend auch als Wirkzusammenhang bezeichnet) derartiger Betriebsparameter untereinander in der Feature-Definition umfassen.
Insbesondere umfasst der Begriff "Entwicklung" hierin neben der Entwicklung neuer physikalischer Funktionsfeatures auch eine Modifikation oder Aktualisierung im Zielgerät bereits implementierter physikalischer
Funktionsfeatures mittels der Feature-Entwickler-Software.
Dabei stellt die im Feature-Development-Framework mit technischen Mitteln (wie z. B. durch eine vorausgehende und/oder entwicklungsprozessbegleitende Prüfung durch Simulation technischer Vorgänge im Zielgerät oder durch eine spezifische Nutzungs- oder Zugriffsregelung in Bezug auf dessen Hardware- Ressourcen) implementierte Einhaltung der mindestens einen vorbestimmten technischen Anforderung in Bezug auf die Feature-Integrierung im Zielgerät stets automatisch sicher, dass das vom Benutzer individuell gestaltete
Funktionsfeature in technischer und rechtlicher Hinsicht einwandfrei und ohne Beeinträchtigung anderer Funktionen in einem Funktionsverbund des Zielgeräts integrierbar ist. Eine zusätzliche Kontrolle dieser Bedingungen durch den Benutzer selbst ist daher nicht erforderlich. Geeignete technische Anforderungen können vom jeweiligen Anwendungsgebiet des Zielgeräts abhängen, einige Beispiele sind weiter unten angegeben.
Im Vergleich zu herkömmlichen in einem Zielsteuergerät implementierbaren Software- Updates, die sich auf starr, d. h. vollständig herstellerseitig festgelegte physikalische Funktionsfeatures beschränken, kann ein Feature-Development- Framework der hierin dargelegten Art dem Benutzer beispielsweise eine vom Hersteller weitgehend unabhängige, insbesondere nach außen nicht
preiszugebende und/oder im Voraus nicht bekannte, Feature-Gestaltung ermöglichen. Ferner kann die Feature-Development-Plattform beispielsweise ein vergleichsweise einfaches, handliches und in Bezug auf die Gestaltungsfreiheit besonders flexibles Software-Tool für den Benutzer darstellen, in dem er in einer technisch und rechtlich automatisch abgesicherten Weise seine eigenen, an einen jeweiligen spezifischen Anwendungsbereich individuell angepassten physikalischen Funktionsfeatures für ein Zielgerät oder eine Zielgeräteklasse entwerfen kann.
Insbesondere kann die hierin dargelegte benutzerseitige Feature-Gestaltung in der Feature-Development-Plattform unter Verwendung einer gängigen
Modellierungsumgebung, wie z. B. Matlab/Simulink, realisiert sein. Insbesondere können dem Benutzer für mindestens ein Funktionsfeature mehrere, beispielsweise zwei, drei, vier oder mehr, unterschiedliche
vorbestimmte Gestaltungs-Eingriffsstellen zur jeweils unterschiedlichen individuellen Modifikation eines herstellerseitig vorgefertigten Standard-Features bereitgestellt sein.
Bei einer spezifischen Ausgestaltung umfasst die mindestens eine vorbestimmte technische Anforderung eine oder mehrere der folgenden Anforderungen:
- Nichtbeeinträchtigung anderer physikalischer Funktionsfeatures im
Zielgerät, wodurch beispielsweise der gegenseitige Einfluss und die Zusammenwirkung verschiedener physikalischer Funktionsfeatures in einem Funktionsverbund des Zielgeräts berücksichtigt sein kann;
- Einhaltung rechtlicher Zulassungsbedingungen für das Zielgerät, wie z. B. die (ECE-)Homologation, etwa bezüglich der Einhaltung zulässiger Emissionsgrenzwerte, bei einem Kraftfahrzeug;
- Einhaltung vorbestimmter Ressourcenanforderungen an die Hardware und Software im Zielgerät, was beispielsweise eine für die Implementierung eines neuen oder geänderten Funktionsfeatures erforderliche Ausstattung des Zielgeräts mit spezifischen Geräten, Sensoren oder IT-Hardware- Ressourcen des Zielsteuergeräts umfassen kann;
- Einhaltung einer vorbestimmten Core-Zuordnung bei einem MultiCore- System im Zielsteuergerät insbesondere zu einer effektiveren Nutzung vorhandener Hardware-Ressourcen und/oder zu einer Zeitoptimierung durch Parallelisierung, wobei der Begriff "Core" hierin für Prozessorkern steht.
Zu der Nichtbeeinträchtigung anderer physikalischer Funktionsfeatures oder den Hardware/Software-Ressourcenanforderungen im Zielgerät können
insbesondere auch folgende Anforderungen zählen:
- Abhängigkeiten zwischen den Funktionsfeatures, etwa "Feature A benötigt Feature B" oder "Feature A schließt Feature B aus", wie z. B. "Distance- Control benötigt Cruise-Control";
- Zielgeräte-Ausstattungen: z. B. kann bei einem Kraftfahrzeug, das wegen der automatischen Notbremsung mit einem Front-Radar ausgestattet ist, nachträglich das ACC (Adaptive-Cruise-Control) heruntergeladen werden. Gemäß einer Ausführungsform stellt mindestens eines der mittels der Feature- Entwickler-Software gestaltbaren Funktionsfeatures eine an der mindestens einen vorbestimmten Gestaltungs-Eingriffsstelle modifizierbare Wirkkette von Wirkzusammenhängen zwischen eine physikalische Feature-Funktionalität im Zielgerät betreffenden Wirk- und Zielparametern dar. Alternativ oder zusätzlich kann mindestens eines der mittels der Feature-Entwickler-Software gestaltbaren Funktionsfeatures mindestens einen an der mindestens einen vorbestimmten Gestaltungs-Eingriffsstelle modifizierbaren Wirkzusammenhang innerhalb einer solchen Wirkkette umfassen. Auf diese Weise können modifizierbare
Funktionsfeatures im Feature-Development-Framework der hierin dargelegten Art in einer einheitlichen und übersichtlichen Weise definiert und insbesondere auch zum Entwerfen zu Beginn des Entwicklungsvorgangs und/oder zur
Überwachung vor, während oder nach der Implementierung im Zielgerät abstrakt modelliert werden.
Zur Definition eines mittels der Feature-Entwickler-Software gestaltbaren
Funktionsfeatures können bei dieser Ausführungsform insbesondere folgende Hilfsbegriffe genutzt werden:
- eine Wirkkette ist eine Abfolge von Wirkzusammenhängen;
- ein Wirkzusammenhang ist eine quantitative Abhängigkeit eines
Zielparameters von einem Wirkparameter (wobei solch ein
Wirkzusammenhang als eine funktionale Komponente in Form einer atomischen Software-Komponente oder mehrerer atomischer Software- Komponenten modelliert und programmiert sein kann);
- ein Zielparameter ist eine physikalische Größe mit einem angestrebten Wert zur Erfüllung einer Funktion im Zielgerät, die von einem oder von mehreren verschiedenen Wirkparametern abhängen kann;
- ein Wirkparameter ist eine physikalische Größe mit kausaler Wirkung auf einen Zielparameter.
Ein mittels der Feature-Entwickler-Software gestaltbares physikalisches
Funktionsfeature kann daher insbesondere:
- eine komplette Wirkkette, die nicht nur linear sein kann, sondern auch
Verzweigungen aufweisen kann, oder ein oder mehrere Wirkzusammenhänge innerhalb einer Wirkkette sein.
Beim Implementieren eines mittels der Feature-Development-Plattform entwickelten Funktionsfeatures in einem Zielgerät kann daher insbesondere:
- eine komplette Wirkkette ersetzt und/oder
- eine komplette Wirkkette hinzugefügt und/oder
- Teil einer existierenden Wirkkette modifiziert werden.
o Dabei kann das Modifizieren insbesondere Folgendes umfassen:
■ das Ersetzen vorhandener Wirkzusammenhänge und/oder
■ das Ändern einer Reihenfolge von Wirkzusammenhängen in der Wirkkette und/oder
■ das Einfügen neuer Wirkzusammenhänge in die Wirkkette und/oder
■ das Entfernen vorhandener Wirkzusammenhänge aus der Wirkkette.
Bezüglich der Reihenfolge der Wirkzusammenhänge in einer Wirkkette können dabei beispielsweise wie folgt Randbedingungen festgelegt sein:
- Wirkzusammenhang (WZH) N folgt unmittelbar auf Wirkzusammenhang K, d. h. Position_WZH_N = Position_WZH_K + 1 oder
- Wirkzusammenhang N muss nach Wirkzusammenhang K abgearbeitet werden (jedoch nicht zwingend unmittelbar), d. h. Position_WZH_N > Position_WZH_K oder
- beliebige Reihenfolge der Wirkzusammenhänge N und K ist zulässig.
Wirk- und Zielparameter können bei dieser Ausführungsform insbesondere Ein- und Ausgangsgrößen für das jeweilige Funktionsfeature oder dessen einzelnen Wirkzusammenhang darstellen. Beispiele für Wirk- oder Zielparameter sind z. B. Drehzahl, Geschwindigkeit, Öffnungsquerschnitt, Temperatur etc. eines
Bauelements oder einer Substanz im Zielgerät.
Gemäß einer Ausführungsform, die insbesondere auch eine Weiterentwicklung der obigen Ausführungsform darstellen kann, ist mindestens eines der in der Feature-Entwickler-Software gestaltbaren physikalischen Funktionsfeatures in der Feature-Entwickler-Software anhand einer formalisierten Wirkkettenbeschreibung, z. B. eines Constraint-Graphen definiert oder beschrieben. Wichtig ist dabei eine eindeutige Beschreibung der Wirkkette und der erlaubten Änderungen an dieser Wirkkette mittels einer formalisierten Methodik und eines geeigneten computergestützten Werkzeugs (nachfolgend kurz: formalisierte Wirkkettenbeschreibung), um sicherzustellen, dass dem Benutzer nur zulässige Modifikationen der Wirkkette an den darin eigens hierzu vorgesehen Gestaltungs-Eingriffsstellen zur Verfügung stehen. Ein Constraint- Graph ist dabei lediglich eine der grundsätzlich beliebigen möglichen Weisen, physikalische Funktionsfeatures und deren vorbestimmte Gestaltungs- Eingriffsstellen in der Feature-Entwickler-Software zu definieren.
Bei einer spezifischen Ausgestaltung des Feature-Development-Frameworks umfasst die Feature-Entwickler-Software eine Simulationssoftware zur
Optimierung mindestens eines der mittels der Feature-Entwickler-Software gestaltbaren Funktionsfeatures hinsichtlich der Hardware-Ressourcennutzung und/oder Wirksamkeit und/oder Zeitausnutzung bei der Implementierung des Funktionsfeatures im Zielgerät und/oder zur Prüfung der Einhaltung mindestens einer der vorbestimmten technischen Anforderungen durch das mindestens eine Funktionsfeature. Dadurch kann das vom Benutzer unter Verwendung der vorbestimmten Gestaltungs-Eingriffsstellen individuell entworfene
Funktionsfeature noch vor seinem Download und der Implementierung im Zielgerät insbesondere vollständig automatisiert geprüft und/oder optimiert werden. Eine automatische Durchführung einer derartigen Prüfung und/oder Optimierung kann grundsätzlich in jedem Stadium der Feature-Entwicklung mittels der Feature-Development-Plattform, d. h. bis zu einem Feature-Download zu dessen Integration im Zielsteuergerät, implementiert sein; sie kann
insbesondere in Teilen oder am Stück und jeweils auch mehrmals während der Feature-Entwicklung erfolgen.
Alternativ oder zusätzlich kann eine derartige Optimierung der mittels der Feature-Entwickler-Software gestalteten Funktionsfeatures oder deren Prüfung im Hinblick auf eine oder mehrere der vorbestimmten technischen Anforderungen auch in dem Feature-Integration-Framework der hierin weiter unten dargelegten Art, d. h. zielsteuergeräteseitig implementiert sein. Gemäß einer Ausführungsform umfasst die Feature-Development-Plattform eine oder mehrere der folgenden Einheiten:
- einen Feature-Preparator, der zum benutzerseitigen Entwerfen des
mindestens einen mittels der Feature-Entwickler-Software gestaltbaren physikalischen Funktionsfeatures ausgebildet ist, indem dem Benutzer solche Funktionsfeatures und deren jeweilige vorbestimmte Gestaltungs- Eingriffsstellen zur Verfügung und/oder Auswahl gestellt sind;
- ein Feature-Development-Kit, das zur Aufbereitung des mindestens einen vom Benutzer individuell gestalteten, insbesondere im Feature-Preparator entworfenen, Funktionsfeatures abhängig von dem jeweiligen Zielgerät und/oder zu dessen Optimierung hinsichtlich der Hardware- Ressourcennutzung, Wirksamkeit und/oder Zeitausnutzung bei der späteren Implementierung im Zielgerät und/oder zu dessen Prüfung auf Einhaltung mindestens einer der vorbestimmten technischen Anforderungen ausgebildet ist;
- einen Feature-Deployment-Checker, der zu einer insbesondere
abschließenden Vorbereitung des mindestens einen vom Benutzer z. B. mittels des Feature-Preparators und/oder des Feature-Development-Kits gestalteten Funktionsfeatures auf dessen Implementierung im jeweiligen Zielgerät und/oder zu dessen Optimierung hinsichtlich der Hardware- Ressourcennutzung, Wirksamkeit und/oder Zeitausnutzung im Zielgerät und/oder zu dessen Prüfung auf Einhaltung mindestens einer der vorbestimmten technischen Anforderungen ausgebildet ist;
- eine Brokering-Plattform, die zum systeminternen, insbesondere
automatisierten und nicht interaktiven, und/oder zum interaktiven, insbesondere vom Benutzer über eine Benutzer-Schnittstelle aktivierbaren, Einbeziehen einer Benutzer-Unterstützung mit einschlägigen Ingenieurs- Dienstleistungen, wie z. B. einem Gerätemanagement oder der
Bereitstellung des im Einzelfall benötigten Fachwissens, und/oder mit einer Beratung, beispielsweise in Fragen einer Software-Lizensierung etc., in den Feature-Entwicklungsprozess ausgebildet ist.
Das Entwerfen eines Funktionsfeatures im Feature-Preparator durch den Benutzer kann beispielsweise eine vom Benutzer gewählte
spezifische/individuelle Gestaltung eines herstellerseitig vorgefertigten Feature- Modells (beispielsweise in Form einer oben beschriebenen Wirkkette) umfassen. Wichtig ist dabei eine eindeutige Beschreibung der Wirkkette und der erlaubten Änderungen an dieser Wirkkette mittels einer formalisierten Methodik und eines geeigneten Werkzeugs, um sicherzustellen, dass dem Benutzer nur zulässige Modifikationen der Wirkkette an den darin vorgesehen Gestaltungs- Eingriffsstellen zur Verfügung stehen. Eine Beschreibungsmöglichkeit dieser Art stellen Constraint-Graphen dar. Dabei kann der Feature-Preparator
insbesondere zu einer parallelen oder anschließenden automatischen
Durchführung einer Prüfung der Einhaltung mindestens einer der vorbestimmten technischen Anforderungen durch das vom Benutzer entworfene
Funktionsfeature ausgebildet sein.
Die Aufbereitung eines vom Benutzer entworfenen Funktionsfeatures im Feature- Development-Kit kann beispielsweise das Erstellen eines dem entworfenen Feature-Modell entsprechenden Software-Codes (Computerprogramm oder auch Software-Paket) sowie dessen Kompilieren, Linken und/oder Lokatieren für das Zielsteuergerät umfassen. Dabei wird unter Lokatieren das Zuweisen bestimmter Teile eines Computerprogramms, sog. Programmsegmente, zu bestimmten Speicherbereichen eines Zielsteuergerätespeichers verstanden.
Durch die Brokering-Plattform kann der Benutzer insbesondere mit nützlichen, z. B. seine Entscheidungsfindung bei der individuellen Feature-Gestaltung erleichternden Informationen über die zur Auswahl stehenden Gestaltungs- Optionen versorgt werden, die von den technischen Auswirkungen einer jeden wählbaren Gestaltungs-Eingriffsstelle des Features auf das Zielgerät bis zu den damit gegebenenfalls verbundenen Lizensierungs-Fragen reichen können.
Bei einer Ausführungsform umfasst das Feature-Development-Framework ferner ein Endanwender-Front-End (hierin als Feature-Store bezeichnet), das eine Feature-Erwerbssoftware für einen Endanwender aufweist, die zum Auffinden und Herunterladen des mindestens einen mittels der Feature-Development- Plattform individuell für einen bestimmten Anwendungsbereich vom Benutzer gestalteten/entwickelten Funktionsfeatures für das Zielgerät ausgebildet ist. Ferner weist das Feature-Store von dieser Erwerbssoftware gesteuerte Zugriffsmechanismen auf Hardware-Ressourcen im Zielgerät und in der von diesem entfernten IT-Infrastruktur auf.
Dabei kann (muss jedoch nicht) der Endanwender eine andere Person als der (hierin auch als Entwickler bezeichnete) Benutzer sein, der das mindestens eine im Feature-Store zum Download angebotene Funktionsfeature unter
Verwendung der Feature-Entwickler-Software individuell gestaltet hat.
Beispielsweise kann der Endanwender ein Halter oder Fahrer eines
Kraftfahrzeugs sein, während der Benutzer ein beim Hersteller des
Kraftfahrzeugs oder beim Arbeitgeber des Fahrers, wie einem
Speditionsunternehmen, eingestellter Ingenieur, Bordelektronik-, Technik- oder Sicherheitsbeauftragter sein kann.
Das Auffinden der anzubietenden Funktionsfeatures im Feature-Store durch den Endanwender kann dabei insbesondere durch die Bereitstellung graphischer Funktionsfeature-Kennzeichnungselemente wie Icons und/oder interaktiver Graphical-User-Interfaces (GUI) erleichtert sein. Dies unterscheidet den im Feature-Store bereitgestellten interaktiven Auswahl- und Download-Vorgang von einem automatischen Feature-Update zusätzlich deutlich. Ferner können im Feature-Store beispielsweise eine computergestützte Bezahlungsmöglichkeit für ein zu erwerbendes Funktionsfeature und/oder eine zusätzliche
Kompatibilitätskontrolle mit der spezifischen Software- und Hardware- Ausstattung des konkreten Zielgeräts implementiert sein. Dies ist über die von der Erwerbssoftware gesteuerten Zugriffe auf Hardware-Ressourcen im Zielgerät und in der von diesem entfernten IT-Infrastruktur realisierbar.
Gemäß einem weiteren Aspekt ist ein Verfahren zur Erstellung eines Feature- Development-Frameworks der hierin dargelegten Art vorgesehen, bei dem für das mindestens eine im Zielgerät implementierbare und mittels der Feature- Entwickler-Software benutzerseitig gestaltbare physikalische Funktionsfeature die mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle entworfen, geprüft und anschließend bereitstellt wird,
- wobei (insbesondere beim Entwerfen und/oder Prüfen der Gestaltungs- Eingriffsstellen) technische Vorgänge, die das mindestens eine
Funktionsfeature bei dessen Implementierung im Zielgerät bewirkt, und deren Zusammenwirkungen mit anderen physikalischen Funktionsfeatures im Zielgerät und/oder mit den Hardware-Ressourcen des Zielgeräts und/oder der von diesem entfernten IT-Infrastruktur simuliert werden, insbesondere mit computergestützten Mitteln, wie z. B. unter Verwendung einer gängigen Simulationsumgebung wie Matlab/Simulink,
- wobei für die technischen Auswirkungen der Gesamtheit der von der
Feature-Entwickler-Software an den Gestaltungs-Eingriffsstellen
bereitgestellten Feature-Gestaltungsmöglichkeiten auf das Zielgerät die Einhaltung mindestens einer der vorbestimmten technischen Anforderungen getestet wird.
Eine Idee dieses Verfahrens besteht darin, dass mit dem zu erstellenden
Feature-Development-Framework einem Benutzer ein einfaches
computergestütztes Tool bereitgestellt wird, mit dem er statt herkömmlicher starr herstellerseitig festgelegter Features in qualitativer Hinsicht vielfältig individuell gestaltete Funktionsfeatures für ein Zielgerät erzeugen kann, wobei ihm jedoch nur technisch und rechtlich unbedenkliche Gestaltungsfreiheiten zur Verfügung stehen. Mit anderen Worten wird dabei bei der Erstellung der benutzerseitigen Gestaltungsfreiheit an den vorbestimmten Gestaltungs-Eingriffsstellen der Funktionsfeatures die Erfüllung der vorbestimmten technischen Anforderungen, die insbesondere alle in technischer und rechtlicher Hinsicht relevanten
Funktionsanforderungen umfassen können, durch Zielgerät-Simulationen geprüft und gesichert.
Gemäß einem weiteren Aspekt ist ein Computerprogramm vorgesehen, welches, wenn es in einem Steuergerät oder einer Datenverarbeitungseinrichtung ausgeführt wird, dazu eingerichtet ist, ein derartiges Verfahren auszuführen.
Gemäß einem weiteren Aspekt ist ein Feature-Integration-Framework zum Integrieren von mittels des Feature-Development-Frameworks der hierin dargelegten Art benutzerseitig individuell gestalteten physikalischen
Funktionsfeatures in einem Funktionsverbund eines Zielgeräts, insbesondere eines Kraftfahrzeugs oder einer Arbeits- oder Werkzeugmaschine, vorgesehen,
- wobei das Feature-Integration-Framework in einem Steuergerät des
Zielgeräts (hierin kurz: Zielsteuergerät) installierbar ist, das insbesondere, jedoch nicht zwingend neben einem Master-Core, auf dem ein
Betriebssystem des Zielsteuergeräts läuft, mindestens einen weiteren Core mit darauf laufenden Virtuellen Maschinen für weitere Software- Anwendungen aufweisen kann, und
- wobei das Feature-Integration-Framework eine oder mehrere der folgenden Komponenten umfasst:
- ein Virtual-Machine-Interface, das dazu ausgebildet ist, auf der Seite einer auf dem Master-Core laufenden Master-Software einen Zugriff auf
Systemkomponenten und -Informationen, die dem Master-Core zugeordnet sind, für auf der/den Virtuellen Maschine(n) laufende weitere Software- Anwendungen bereitzustellen;
- mindestens einen Virtual-Machine-Adapter, der jeweils als Gegenstück des Virtual-Machine-Interface auf jeder der Virtuellen Maschinen dazu ausgebildet ist, Funktionsaufrufe einer auf der jeweiligen Virtuellen
Maschine laufenden weiteren Software-Anwendung aufzufangen und dem Virtual-Machine-Interface zu übergeben;
- einen Feature-Proxy-on-Device, der dazu ausgebildet ist, den zu
integrierenden individuell gestalteten physikalischen Funktionsfeatures den Zugriff auf darin definierte Wirk- und Zielparameter des Zielgeräts bereitzustellen;
- einen Feature-Coordinator-on-Device, der dazu ausgebildet ist, jedes zu integrierende oder bereits integrierte individuell gestaltete physikalische Funktionsfeature mit den übrigen Hardware- und Software-Ressourcen des Zielgeräts zu koordinieren, insbesondere diese Funktionsfeatures zu schedulen, starten und/oder stoppen.
Eine Idee dieses Feature-Integration-Frameworks besteht darin, dass es dazu ausgebildet ist, auch neue oder geänderte Funktionsfeatures im Zielsteuergerät zu installieren, die nicht im Voraus starr herstellerseitig vorgegeben sind, sondern in qualitativer Hinsicht herstellerunabhängig von einem Benutzer, beispielsweise mittels eines Feature-Development-Frameworks der hierin dargelegten Art, erzeugt wurden.
Insbesondere ermöglicht das Feature-Integration-Framework somit das Hosten der mittels des Feature-Development-Frameworks der hierin dargelegten Art benutzerseitig individuell gestalteten physikalischen Funktionsfeatures im
Zielsteuergerät. Dadurch kann insbesondere eine kontrollierte und einwandfreie Ausführung dieser Funktionsfeatures durch das Zielsteuergerät und damit deren Implementierung im Zielgerät ermöglicht werden.
Insbesondere kann das Feature-Integration-Framework bzw. seine einzelnen Komponenten wie der Feature-Proxy-on-Device und/oder Feature-Coordinator- on-Device dazu ausgebildet sein, mit dem Feature-Development-Framework der hierin dargelegten Art zu kommunizieren, beispielsweise Informationen oder Software auszutauschen oder Aufrufe zur Durchführung eines Tests und/oder einer Simulation weiterzugeben. Dies kann insbesondere einem Datenaustausch und/oder einem Hardwareabgleich in Bezug auf die über die Feature- Development-Plattform individuell gestalteten Funktionsfeatures dienen, z. B. zum Zwecke einer Hardware- und Software-Kompatibilitätskontrolle mit dem Zielgerät und dessen Funktionsverbund und/oder einer Überwachung zur Sicherstellung einer einwandfreien Funktion dieser neu integrierten
Funktionsfeatures zu deren Laufzeit im Zielgerät.
Gemäß einer Ausführungsform des Feature-Integration-Frameworks ist zur Sicherstellung der funktionalen Integrität des gesamten Funktionsverbunds des Zielgeräts bei der Implementierung der individuell gestalteten physikalischen Funktionsfeatures, insbesondere zur Einhaltung mindestens einer der obigen vorbestimmten technischen Anforderungen, der Feature-Proxy-on-Device ferner dazu ausgebildet, zumindest einige Wirkzusammenhänge der zu integrierenden oder bereits integrierten individuell gestalteten physikalischen Funktionsfeatures vorzugsweise du deren Laufzeit zu überwachen. Dies kann insbesondere durch ein im Feature-Proxy-on-Device implementiertes Modellieren und/oder
Simulieren des jeweiligen im Feature-Preparator definierten Feature-Verhaltens realisiert sein.
Alternativ oder zusätzlich ist bei dieser Ausführungsform der Feature- Coordinator-on-Device zu demselben Zweck dazu ausgebildet, zumindest einige der zu integrierenden oder bereits integrierten individuell gestalteten
physikalischen Funktionsfeatures, insbesondere durch das Generieren abstrakter Beobachtermodelle anhand der jeweiligen im Feature-Preparator definierten Feature-Freiheitsgrade, zu überwachen und/oder bei Fehler oder Ausfall eines oder mehrerer dieser oder anderer Funktionsfeatures oder eines Teils davon Ersatzwerte für ausgefallene Funktionsfeatures oder deren einzelne Teile oder einzelne Wirk- oder Zielparameter bereitzustellen. Durch den Einsatz derartiger Ersatzwerte kann eine funktionale Integrität des gesamten Funktionsverbunds des Zielgeräts selbst dann gewährleistet sein, wenn eine Fehlerdiagnose bei der Überwachung eines neu implementierten Funktionsfeatures vorliegt und/oder ein Ausfall einer zu dessen Durchführung benötigten Hardware- oder
Softwarekomponente im Zielgerät eintritt. Derartige Ersatzwerte können auch Ersatzvariablen mit mehreren verschiedenen situationsabhängig vorbestimmten Werten sein.
Beispiele geeigneter im Feature-Proxy-on-Device oder dem Feature-Coordinator- on-Device implementierter Simulations-, Überwachungs- und Beobachtermodelle sind weiter unten angegeben. Alternativ oder zusätzlich kann die Funktionalität gemäß dieser Ausführungsform auch zumindest teilweise über die oben erwähnte Kommunikation mit dem Feature-Development-Framework
implementiert sein, d. h. dessen oben beschriebene Einheiten wie den Feature- Preparator, den Feature-Development-Checker, das Feature-Development-Kit oder die darin implementierte spezielle geeignete Simulationssoftware mitnutzen.
Gemäß einem weiteren Aspekt ist ein Steuergerät zum Steuern eines
Funktionsverbunds eines Zielgeräts, insbesondere eines Kraftfahrzeugs oder einer Arbeits- oder Werkzeugmaschine, vorgesehen, wobei das Steuergerät ein Feature-Integration-Framework der hierin dargelegten Art aufweist. Insbesondere kann es sich dabei um das hierin an anderen Stellen erwähnte Zielsteuergerät handeln. Beispielsweise kann das Steuergerät dabei neben einem Master-Core, auf dem ein Betriebssystem des Steuergeräts läuft, mindestens einen weiteren Core mit darauf laufenden Virtuellen Maschinen für weitere Software- Anwendungen aufweisen.
Gemäß einem weiteren Aspekt ist ein maschinenlesbares Speichermedium vorgesehen, auf dem ein Feature-Development-Framework und/oder ein
Computerprogramm zur Implementierung eines Verfahrens zu seiner Erstellung und/oder ein Feature-Integration-Framework der hierin dargelegten Art gespeichert sind.
Kurzbeschreibung der Zeichnungen
Die obigen Aspekte und deren Ausführungsformen und spezifische
Ausgestaltungen werden nachfolgend anhand der in beigefügten Zeichnungen dargestellten Beispiele näher erläutert. Die Zeichnungen sind rein schematisch, sie sind insbesondere nicht als maßstabsgetreu zu lesen. Ähnliche oder einander entsprechende Elemente sind darin mit gleichen Bezugszeichen versehen und deren wiederholte Beschreibung ist teilweise weggelassen. Es zeigen:
Figur 1 eine schematische Übersichtsdarstellung einer
wechselseitigen Kommunikation zwischen einem Feature- Development-Framework der hierin dargelegten Art, einem in einem Zielsteuergerät installierten Feature-Integration- Framework der hierin dargelegten Art und einer vom
Zielgerät entfernten IT-Infrastruktur;
Figur 2 eine schematische Übersicht einer beispielhaften
Schrittabfolge von der individuellen Feature-Gestaltung durch einen Benutzer eines Feature-Development- Frameworks der hierin dargelegten Art bis zum
Implementieren und Überwachen eines solchen individuell gestalteten Funktionsfeatures in einem Zielgerät unter Einsatz eines Feature-Integration-Frameworks der hierin dargelegten Art;
Figur 3 eine schematische Übersicht einer beispielhaften
Schrittabfolge von der individuellen Feature-Gestaltung durch einen Benutzer eines Feature-Development- Frameworks der hierin dargelegten Art bis zum Aussuchen und Implementieren eines solchen individuell gestalteten Funktionsfeatures in einem Zielgerät durch einen Endanwender unter Einsatz eines Feature-Integration- Frameworks der hierin dargelegten Art;
Figur 4 und 5 mögliche Darstellung von in einer Feature-Development- Plattform der hierin dargelegten Art individuell gestaltbaren physikalischen Funktionsfeatures in Form an vorbestimmten Gestaltungs-Eingriffsstellen modifizierbarer Wirkketten;
Figur 6 ein Beispiel der Beschreibung der modifizierbaren Wirkkette der Fig. 5 durch eine formalisierte Wirkkettenbeschreibung, z. B. mittels eines Constraint-Graphen;
Figur 7 eine veranschaulichende Darstellung der Feature- Entwicklungsschritte gemäß der Fig. 3 in einer Feature- Development-Plattform der hierin dargelegten Art;
Figur 8 eine Detaildarstellung in der Feature-Development-Plattform der Figuren 3 und 7 implementierter Simulations- und Testschritte;
Figur 9 eine schematische Darstellung eines Beispiels der Software- Architektur eines in einem Zielsteuergerät installierten Feature-Integration-Frameworks der hierin dargelegten Art;
Figur 10 das Feature-Integration-Framework der Figur 9 separat; Figur 1 1 ein schematischen Blockschaltbild eines Beispiels in einem
Feature-Proxy-on-Device der hierin dargelegten Art implementierter Ausführungsschritte für ein neues
Funktionsfeature des Zielgeräts;
Figur 12 ein schematisches Blockschaltbild eines Beispiels in einem
Feature-Coordinator-on-Device der hierin dargelegten Art implementierter Überwachungsschritte für ein neues Funktionsfeature des Zielgeräts; Figur 13 ein schematisches Diagramm eines in einem Feature- Coordinator-on-Device der hierin dargelegten Art generierten und zur Überwachung eines neu gestalteten
Funktionsfeatures des Zielgeräts implementierten
Beobachtermodells;
Figur 14 ein schematisches Blockdiagramm einer
Kommunikationsbeziehung des Feature-Coordinator-on- Device und möglicher weiterer Elemente des Feature- Integration-Frameworks der Figur 9 zwischen einer Virtuellen Maschine, auf der ein neues Funktionsfeature läuft, und einer auf einem Master-Core des Zielsteuergeräts laufenden Master-Software.
Beschreibung von Ausführungsformen
Alle weiter oben in der Beschreibung und in den nachfolgenden Ansprüchen erwähnten verschiedenen Ausführungsformen, Varianten und spezifischen Ausgestaltungsmerkmale des Feature-Development-Frameworks gemäß dem obigen ersten Aspekt sowie des Verfahrens zu dessen Erstellung, des entsprechenden Computerprogramms, des Feature-Integration-Frameworks, des Steuergeräts und des maschinenlesbares Speichermediums gemäß den obigen weiteren Aspekten können sinngemäß bei den in Figur 1 bis 14 gezeigten Beispielen einzeln oder in oben erwähnten Kombinationen implementiert sein.
Sie werden daher nachfolgend nicht alle nochmals wiederholt. Das Gleiche gilt entsprechend für die weiter oben bereits angegebenen Begriffsdefinitionen und Wirkungen in Bezug auf einzelne Merkmale, die in den Figuren 1 bis 14 gezeigt sind.
Figur 1 illustriert ein Beispiel möglicher IT-Komponenten für eine Cloud-basierte benutzer-, d. h. kundenseitige individuelle Gestaltung physikalischer
Funktionsfeatures für ein Zielgerät, wie z. B. ein Kraftfahrzeug oder eine Arbeits- oder Werkzeugmaschine. Dabei zeigt die Figur 1 in einer schematischen Übersicht folgende zur gegenseitigen Kommunikation ausgebildete Elemente: ein Feature-Development-Framework 1 der hierin dargelegten Art, ein in einem Steuergerät 2 eines Zielgeräts 3 (kurz: Zielsteuergerät 2) installiertes Feature- Integration-Framework 4 der hierin dargelegten Art und eine vom Zielgerät 3 entfernte IT-Infrastruktur 5 (Cloud, beispielsweise Bosch-loT-Cloud & Services oder BIC).
Das Zusammenspiel zwischen diesen Elementen wird weiter unten zum Schluss mit Bezug auf Figur 2 erläutert, nachdem das Feature-Development-Framework
1 anhand der Figur 3 bis 8 und das Feature-Integration-Framework 4 anhand der Figur 9 bis 14 im Detail beschrieben sind. Bei den in den Figuren gezeigten Beispielen stellt das Zielgerät 3 rein beispielhaft ein Kraftfahrzeug dar, das insbesondere ein Nutzfahrzeug sein kann.
Für drahtlose Software-Aktualisierungen des Zielgeräts 3 sind im Zielsteuergerät
2 Over-The-Air-Schnittstellen vorgesehen (nicht gezeigt). Abhängig von der Elektrik/Elektronik-Architektur des Zielgeräts 3, wie der Partitionierung von Funktionen im Zielsteuergerät 2 und deren Vernetzung, kann im Zielgerät 3 als ein Extraniveau der Sicherheit zusätzlich ein Security-Gateway (nicht gezeigt) vorgesehen sein, um einen Einbruch in diese Over-The-Air-Schnittstellen zusätzlich zu erschweren. Mit einem Cloud-basierten Ansatz gemäß Fig. 1 lässt sich eine universelle Umgebung bereitstellen, die im Prinzip von überall und grundsätzlich jedem Benutzer zugänglich ist.
Zunächst wird nachfolgend ein Feature-Development-Framework 1 der hierin dargelegten Art mit Bezug auf Figuren 1 und 3 bis 8 erläutert:
Wie in Fig. 1 gezeigt, weist das Feature-Development-Framework 1 eine
Feature-Development-Plattform 1 a auf, die zur individuellen, d. h. qualitativ unterschiedlichen Gestaltung physikalischer Funktionsfeatures für das Zielgerät 3 durch einen Benutzer 10 (in Fig. 2 und 3 gezeigt) ausgebildet ist. Wie eingangs erwähnt, kann die qualitativ unterschiedliche Feature-Gestaltung durch den Benutzer 10 der Feature-Development-Plattform 1 a an den darin bereitgestellten vorbestimmten Gestaltungs-Eingriffsstellen insbesondere eine über rein quantitative Parameteranpassungen hinausgehende Modifikation eines herstellerseitig bereitgestellten Standard-Features bedeuten. Dies kann beispielsweise das Hinzufügen weiterer technischer Betriebsparameter (z. B. als Wirk- und Zielparameter in der weiter oben und auch in Bezug auf Fig. 6-8 beschriebenen Wirkketten-Definition eines Funktionsfeatures) des Zielgeräts 3, wie z. B. einer Drehzahl oder eines Öffnungsquerschnitts eines Bauteils etc., und/oder eine Änderung oder Hinzufügung eines logischen und/oder
physikalischen Abhängigkeitsprinzips derartiger Betriebsparameter untereinander in der Feature-Definition umfassen (vgl. Fig. 6-8).
Insbesondere umfasst der Begriff "Entwicklung" hierin neben der Entwicklung neuer physikalischer Funktionsfeatures auch eine Modifikation oder
Aktualisierung im Zielgerät 3 bereits implementierter physikalischer
Funktionsfeatures mittels der Feature-Development-Plattform 1 a.
Ferner umfasst das Feature-Development-Framework 1 in der Ausführungsform gemäß Fig. 1 ein Feature-Store 1 b mit einer Feature-Erwerbssoftware (nicht gezeigt) zum Auffinden und Herunterladen der mittels der Feature-Development- Plattform 1 a entwickelten Funktionsfeatures durch einen Endanwender 11 (in Fig. 2 und 3 gezeigt).
Das Feature-Store 1 b stellt ein Endanwender-Front-End dar, um benötigte neue Funktionsfeatures zu finden und auszuwählen. Weiterhin kann es dem
Endanwender 11 insbesondere auch Mechanismen zur Verfügung stellen, um eine Bezahlung für die erworbenen Funktionsfeatures vorzunehmen. Ferner kann das Feature-Store 1 b beispielsweise zur Kopplung zu einer FOTA-Infrastruktur (Firmware-Update-Over-The-Air) und/oder einer SOTA-Infrastruktur (Software- Update-Over-The-Air) ausgebildet sein, um automatisch eine richtige Version einer Firmware oder eines Funktionsfeatures für ein spezifisches Zielgerät 3 bzw. dessen Zielsteuergerät 2 auszuwählen. Dabei kann das Feature-Store 1 b insbesondere auch dazu ausgebildet sein, auf das richtige und korrekte
Zusammenspiel des ausgewählten Funktionsfeatures mit der restlichen (bereits existierenden) Software und Firmware im Zielgerät 3 zu achten, insbesondere die Erfüllung mindestens einer der vorbestimmten technischen Anforderungen der hierin dargelegten Art zu prüfen oder sicherzustellen. Im Feature-Development-Framework 1 der Fig. 1 ist es die essentielle Prämisse dafür, dass ein neues Funktionsfeature im Feature-Store 1 b ausgewählt und heruntergeladen werden kann, dass es zunächst entwickelt werden muss. Die Feature-Development-Plattform 1 a stellt dem Benutzer 10 eine Umgebung bereit, mit der ein benötigtes Funktionsfeature individuell gestaltet werden kann. Hierzu umfasst sie bei der spezifischen Ausgestaltung gemäß der Figur 1 folgende vier Einheiten: den Feature-Preparator 6, das Feature-Development-Kit 7, den Feature-Deployment-Checker 8 und eine Brokering-Plattform 9. Dabei ist die Brokering-Plattform 9 zum Einbeziehen einer Benutzer-Unterstützung hinsichtlich einschlägiger Ingenieurs-Dienstleistungen wie eines Geräte-Managements etc. (Untereinheit 9a), einer Lizensierung (Untereinheit 9b) und sonstiger Beratung (Untereinheit 9c) in den Feature-Entwicklungsprozess ausgebildet und kann daher in der Feature-Development-Plattform 1 a sowohl eigenständig oder zusammen mit einer oder mehreren der anderen drei Einheiten implementiert sein. Das mögliche Zusammenspiel zwischen diesen drei Einheiten und deren jeweilige Eigenschaften werden nachfolgend mit Bezug auf Figur 3 näher erläutert.
Figur 3 zeigt eine schematische Übersicht einer möglichen Schrittabfolge von der individuellen Feature-Gestaltung durch einen Benutzer 10 eines Feature- Development-Frameworks 1 der hierin dargelegten Art bis zum Aussuchen und Implementieren eines solchen individuell gestalteten Funktionsfeatures in einem Zielgerät 3 durch einen Endanwender 1 1 , z. B. einen Fahrer des Kraftfahrzeugs, unter Einsatz eines Feature-Integration-Frameworks 4 der hierin dargelegten Art. Dabei kann es sich insbesondere um das Feature-Development-Framework 1 und das Feature-Integration-Framework 4 der Fig. 1 handeln.
In Figur 3 wird zunächst eine mögliche Ausgestaltung des Feature-Preparators 6 der Feature-Development-Plattform 1 a beschrieben. Der Feature-Preparator 6 ist zum benutzerseitigen Entwerfen physikalischer Funktionsfeatures ausgebildet, indem er dem Benutzer 10 mindestens ein solches Funktionsfeature,
beispielsweise in Form eines herstellerseitig vorgefertigten Standard-Features, mit vorbestimmten Gestaltungs-Eingriffsstellen jeweils zu einer zulässigen individuellen Feature-Modifikation bereitstellt. Die Feature-Entwicklung in der Feature-Development-Plattform 1a, insbesondere die herstellerseitige Erstellung der Standard-Features mit den vorbestimmten Gestaltungs-Eingriffsstellen und/oder die individuelle Feature-Gestaltung durch den Benutzer 10 im Feature-Preparator 6, kann beispielsweise mit
modellbasierten Methoden unterstützt sein. Insbesondere kann ein
Funktionsfeature dabei in einer gängigen Modellierungsumgebung, wie z. B. Matlab/Simulink, entworfen und simuliert werden. In diesem Zusammenhang kann insbesondere auch die Durchführung einer Modellprüfung, etwa mit einem Model-Advisor, implementiert sein, um das Einhalten vorbestimmter Modell- Anforderungen in Form interner Regelwerk-Richtlinien sicherzustellen, die auch technische Anforderungen der weiter oben genannten Art umfassen können. All diese Feature-Entwicklungsschritte sind in Figur 3 im Schritt Q1
zusammengefasst, der in einer grundsätzlich beliebigen Reihenfolge (in Fig. 3 durch Rundpfeile angedeutet) mit folgenden weiteren Schritten Q2 und Q3 kombiniert sein kann:
Für die Entwicklung eines Funktionsfeatures ist insbesondere die
herstellerseitige Bereitstellung und benutzerseitige Auswahl im Zielgerät 3 vorhandener Schnittstellen im Schritt Q2 wichtig, die z. B. in die Definition der vorbestimmten Gestaltungs-Eingriffsstellen und einzelner Ziel- und
Wirkparameter eines Funktionsfeatures eingehen können. Im Schritt Q3 können weitere für die Entwicklung eines Feature-Modells relevante Informationen über die im Zielgerät 3 vorhandene Software-Architektur beispielsweise in Form eines "data-dictionary" bereitgestellt werden. Darin können relevante
Ausstattungsdaten, insbesondere über im Zielgerät 3 vorhandene funktionale Komponenten, sowie Messages und/oder Variablen, die durch die neuen Funktionsfeatures verändert werden dürfen, enthalten sein. Dabei wird unter "Message" eine Kommunikationsvariable zwischen Software-Komponenten verstanden, wobei Messages durch physikalische Einheiten, Quantisierung, Wertebereiche und/oder Updatehäufigkeit charakterisiert sein können.
Fig. 4 und 5 zeigen Beispiele einer möglichen Darstellung benutzerseitig individuell gestaltbarer Funktionsfeatures im Feature-Preparator 6 in Form an vorbestimmten Gestaltungs-Eingriffsstellen modifizierbarer Wirkketten W1 , W2, W3 und W5. Dabei können insbesondere folgende Hilfsbegriffe verwendet werden:
- eine Wirkkette ist eine Abfolge von Wirkzusammenhängen;
- ein Wirkzusammenhang ist eine quantitative Abhängigkeit eines
Zielparameters von einem Wirkparameter (wobei solch ein
Wirkzusammenhang als eine funktionale Komponente in Form einer atomischen Software-Komponente oder mehrerer atomischer Software- Komponenten modelliert und programmiert sein kann);
- ein Zielparameter ist eine physikalische Größe mit einem angestrebten Wert zur Erfüllung einer Funktion im Zielgerät 3, die von einem oder von mehreren verschiedenen Wirkparametern abhängen kann;
- ein Wirkparameter ist eine physikalische Größe mit kausaler Wirkung auf einen Zielparameter.
Ein mittels der Feature-Development-Plattform 1 a gestaltbares physikalisches Funktionsfeature kann daher insbesondere:
- eine komplette Wirkkette sein, die nicht nur linear sein kann, sondern auch Verzweigungen aufweisen kann, oder
- ein oder mehrere Wirkzusammenhänge innerhalb einer Wirkkette sein.
Beim Implementieren eines mittels der Feature-Development-Plattform 1a entwickelten Funktionsfeatures in einem Zielsteuergerät 2 kann insbesondere:
- eine komplette Wirkkette ersetzt und/oder
- eine komplette Wirkkette hinzugefügt und/oder
- Teil einer existierenden Wirkkette modifiziert werden.
Das Modifizieren einer existierenden Wirkkette im Zielsteuergerät 2, oder aber das einem Benutzer 10 erlaubte Modifizieren eines herstellerseitig vorgefertigten Standard-Features an den vorbestimmten Gestaltungs-Eingriffsstellen in der Feature-Development-Plattform 1 a kann insbesondere Folgendes umfassen:
- das Ersetzen vorhandener Wirkzusammenhänge und/oder
- das Ändern einer Reihenfolge von Wirkzusammenhängen in der Wirkkette und/oder
- das Einfügen neuer Wirkzusammenhänge in die Wirkkette und/oder das Entfernen vorhandener Wirkzusammenhänge aus der Wirkkette.
Bezüglich der Reihenfolge der Wirkzusammenhänge in einer Wirkkette können dabei beispielsweise wie folgt Randbedingungen festgelegt sein:
- Wirkzusammenhang N folgt unmittelbar auf Wirkzusammenhang K, d. h.
Position_WZH_N = Position_WZH_K + 1 oder
- Wirkzusammenhang N muss nach Wirkzusammenhang K abgearbeitet werden (nicht nur unmittelbar), d. h. Position_WZH_N > Position_WZH_K oder
- beliebige Reihenfolge der Wirkzusammenhänge N und K ist zulässig.
Zur Nichtbeeinträchtigung anderer physikalischer Funktionsfeatures oder zur Erfüllung erforderlicher Hardware/Software-Ressourcenanforderungen im
Zielgerät 3 kann im Feature-Preparator 6 die Prüfung vorbestimmter technischer Anforderungen der hierin dargestellter Art implementiert sein, z. B. bezüglich spezifischer
- Abhängigkeiten zwischen den Funktionsfeatures, etwa "Feature A benötigt Feature B" oder "Feature A schließt Feature B aus", z. B. "Distance-Control benötigt Cruise-Control";
- Zielgeräte-Ausstattungen: z. B. kann bei einem Kraftfahrzeug, das wegen der automatischen Notbremsung mit einem Front-Radar ausgestattet ist, nachträglich das ACC (Adaptive-Cruise-Control) heruntergeladen werden.
In den Wirkketten W1 , W2, W3... der Fig. 4 und 5 kennzeichnet jedes Rechteck S1 , S12, S2, S2', S3... im allgemeinsten Sinne ein Subsystem, das einen einzelnen oder mehrere Wirkzusammenhänge beinhalten kann. Dabei sind erlaubte (d. h. dem Benutzer 10 im Feature-Preparator 6 zur Verfügung gestellte) Modifikationen der Wirkketten W1 , W2, W3 und W5 an den vorbestimmten Gestaltungs-Eingriffsstellen durch gestrichelte Rechtecke und Verbindungslinien gekennzeichnet. Hingegen können die Wirkketten W1 , W2, W3, W4 und W5 in den Fig. 4 bis 6 an ihren mit durchgezogenen Linien gezeichneten Teilen nicht vom Benutzer 10 modifiziert werden.
Wirk- und Zielparameter können dabei insbesondere Ein- und Ausgangsgrößen für eine Wirkkette oder deren einzelnen Wirkzusammenhang darstellen. Beispiele für Wirk- und Zielparameter sind z. B. Drehzahl, Geschwindigkeit, Öffnungsquerschnitt, Temperatur etc. eines Bauelements oder einer Substanz im Zielgerät 3 sein. Die oben aufgeführte Systematik der äußeren Beziehungen von Wirkzusammenhängen kann auch für die Beschreibung der Ein- und
Ausgangsbeziehungen innerhalb von Wirkzusammenhängen Anwendung finden, z. B.: Eingang A hat nur Auswirkung auf Ausgang D und nicht auf Ausgang C.
Zur Entwicklung oder Aktualisierung eines Zielsteuergeräts 2 können mehrere derartige Wirkketten (z. B. Drehmomenten-Wirkkette, Luftzufuhr-Wirkkette etc.) sowie deren Zusammenspiel mittels der Feature-Development-Plattform 1 a zu definieren sein, die später von einer Steuergerätesoftware zu implementieren sind. Letzteres kann z. B. durch ein Feature-Integration-Framework 4 der hierin dargelegten Art, insbesondere gemäß den Fig. 9-14, realisiert sein.
Für jede in der Feature-Development-Plattform 1a zur benutzerseitigen
Gestaltung implementierte Wirkkette werden/sind die erlaubten Modifikationen der oben genannten Arten aufgelistet. Die Wirkketten und deren erlaubte
Modifikationen können dabei z. B. anhand von Constraint-Graphs beschrieben werden (vgl. Fig. 6). Hierfür werden die Constraint-Graphs mit Attributen erweitert, die die erlaubten Modifikationen charakterisieren. Die Summe dieser Attribute definiert die Freiheitsgrade zur möglichen Optimierung der gesamten Wirkketten, z. B. hinsichtlich der Hardware-Ressourcennutzung und/oder Wirksamkeit und/oder Zeitausnutzung bei der Implementierung des durch die Wirkkette definierten Funktionsfeatures im Zielgerät 3. Dazu kann in diesem Fall beispielsweise ein Suchalgorithmus zu einer optimalen Reihenfolge von
Wirkzusammenhängen in einer Wirkkette in der Feature-Development-Plattform 1 a, insbesondere im Feature-Preparator 6, implementiert sein.
Eine derartige Optimierung der Wirkkette und/oder deren Prüfung auf die Einhaltung mindestens einer der vorbestimmten technischen Anforderungen der hierin dargelegten Art kann sowohl im Feature-Preparator 6 als auch in anderen Einheiten der Feature-Development-Plattform 1a in weiteren Schritten Q6 (Optimierung) und Q7-Q8 (Prüfung) der Fig. 3 im Zusammenhang mit einer Simulation Q5 des Features implementiert sein. Insbesondere kann dabei im Hinblick auf ein MultiCore-System im Zielsteuergerät 2 festgelegt werden, welche Funktionsfeatures (Wirkketten bzw. Teile davon) parallelisierbar sind, um eine volle Performance bzgl. des Core-Balancing zu erhalten. Ferner kann durch Optimierung oder eine zu erfüllende vorbestimmte technische Anforderung auch die Zuordnung von Funktionsfeatures zu bestimmten Cores implementiert sein und/oder dass bestimmte Features unbedingt auf dem gleichen Core laufen müssen oder nicht auf dem gleichen Core laufen dürfen. Auf ähnliche Weise können Ressourcenanforderungen (Speicherbedarf - RAM, Flash- Echtzeitanforderungen, Laufzeitbedarf, Jitter, Latenzzeiten etc.) im
Zielsteuergerät 2 im Vorfeld definiert und/oder bei der Feature-Optimierung berücksichtigt werden.
Fig. 5 und 6 zeigen ein Beispiel der Definition einer Wirkkette W5 mit dem Benutzer 10 erlaubten Modifikationen durch eine formalisierte
Wirkkettenbeschreibung. Fig. 5 und 6 zeigen jeweils zum Vergleich eine herstellerseitig starr festgelegte Standard-Wirkkette W4 aus drei aufeinander folgenden Subsystemen S1 , S2 und S3 (die z. B. einzelne Wirkzusammenhänge sein können), die nicht benutzerseitig modifizierbar ist. Hingegen kann die in der Feature-Development-Plattform 1a bereitgestellte Wirkkette W5 vom Benutzer 10 an deren in Fig. 5 gestrichelt eingezeichneten Elementen zwischen den
Subsystemen S1 und S3 individuell gestaltet werden.
Die an diesen Gestaltungs-Eingriffsstellen erlaubten Modifikationen der Wirkkette W5 sind mittels der formalisierten Wirkkettenbeschreibung gemäß der Fig. 6 definiert. Die darin enthaltenen Verknüpfungen durch XOR-Gatter geben vor, dass das optionale Subsystem S2' eine "entweder oder"-Alternative zu dem Subsystem S2 ist, genauso wie das aufgrund des AND-Gatters mit weiteren Subsystemen S4 und S5 fest verbundene optionale Subsystem S23' eine "entweder oder"-Alternative zu dem optionalen Subsystem S23 darstellt. Ferner gibt der OR-Gatter vor, dass der Benutzer 10 über das Hinzufügen des optionalen Subsystems S12 sowie einer der beiden Alternativen S23 bzw. S23'- S4-S5 frei entscheiden kann.
Nachdem die Modellierung des Funktionsfeatures im Feature-Preparator 6 abgeschlossen ist, kann in einem weiteren Schritt Q4 der Fig. 3 beispielsweise unter Einsatz des Feature-Development-Kits 7 der Fig. 1 der Software-Code für das Funktionsfeature automatisch generiert werden und für ein spezifisches Zielsteuergerät 2 (wie z. B. Fahrzeugführungsrechner bzw. VCU, Vehicle- Control-Unit) kompiliert, gelinkt und lokatiert werden. Um diverse Anforderungen an das Funktionsfeature zu erfüllen, wie z. B. Software-Qualität oder
vorbestimmte technische Anforderungen wie "Safety and Security" etc., wird das entwickelte Funktionsfeature in weiteren, weiter oben erwähnten Schritten Q5 bis Q8 simuliert und getestet, die beispielsweise ebenfalls im Feature-Development- Kit 7 oder zumindest teilweise im Feature-Deployment-Checker 8 implementiert sein können.
Das Simulieren Q5 und Testen Q7 kann dabei mehrstufig verlaufen, wie in Fig. 8 symbolisch veranschaulicht: in einem ersten Schritt Q57a kann beispielsweise durch Simulation des einzelnen Funktionsfeatures allein sichergestellt werden, dass seine Implementierung (an dieser Stelle im Sinne des generierten und für die Simulation kompilierten Codes) den vorgegebenen Anforderungen des gewünschten Features entspricht, z. B. durch einen sogenannten MIL-SIL- Vergleich für Model-In-The-Loop und Software-In-The-Loop. In einem weiteren Schritt Q57b kann verifiziert werden, ob das korrekte Einfügen des so implementierten Funktionsfeatures in die bestehenden Wirkketten des Zielgeräts 3 erfolgt ist. Weitere Simulationstests Q57c in einer noch umfassenderen Zielgeräte-Architektur können der Sicherstellung einer einwandfreien Integration des neuen Funktionsfeatures im bestehenden Funktionsverbund des Zielgeräts 3 dienen.
Im Rahmen der Schritte Q57a bis Q57c der Fig. 8 können insbesondere sogenannte statische Tests und Festlegungen der Funktionsfeatures
implementiert sein, z. B. in Bezug auf
- die Einplanungsreihenfolge (scheduling sequence) verschiedener
Wirkketten untereinander oder auch innerhalb der Wirkketten im
Zielsteuergerät 2;
- Position bestimmter Wirkzusammenhänge relativ zu anderen
Wirkzusammenhängen im Zielgerät 3;
- zeitlich synchronisierte und/oder (motor-)drehzahlsynchronisierte
Wirkkettenimplementierung im Zielgerät 3; und/oder - erforderliche Ein- und Ausgangsbeziehungen für die Wirkketten und die einzelnen Wirkzusammenhänge im Zielgerät 3.
Ferner können im Rahmen der Schritte Q57a bis Q57c insbesondere auch funktionsrelevante Tests und Festlegungen der Funktionsfeatures implementiert sein, z. B. in Bezug auf
- das Vorhandensein erforderlicher Ressourcen wie RAM, Flash etc. im
Zielsteuergerät 2;
- die funktionale Integrierbarkeit des Funktionsfeatures im Zielsteuergerät 2 abhängig von anderen Funktionsfeatures des Funktionsverbunds und der Geräteausstattung des Zielgeräts 3 etc.
In den Schritten Q57b-Q57c kann also jeweils insbesondere die Erfüllung dieser und anderer der hierin beschriebenen vorbestimmten technischen Anforderungen geprüft und sichergestellt werden. Zusätzlich kann das Funktionsfeature im obigen Optimierungsschritt Q6 dahin gehend optimiert werden, dass mit den im Zielgerät 3 vorhandenen Ressourcen möglichst sorgfältig umgegangen wird.
Die Erfüllung der vorbestimmten technischen Anforderungen der "Safety and Security" kann auch im Feature-Integration-Framework 4 der hierin dargelegten Art, aufgrund deren Wichtigkeit insbesondere auch zusätzlich, implementiert sein.
Ähnlich kann die Erfüllung der vorbestimmten technischen Anforderungen in Bezug auf die Homologation des Zielgeräts 3, insbesondere eines
Kraftfahrzeugs, in einem Schritt Q8 der Fig. 3 in dem Feature-Development-Kit 7 und/oder dem Feature-Deployment-Checker 8 oder insbesondere auch zusätzlich im Feature-Integration-Framework 4 der hierin dargelegten Art implementiert sein. Diese Prüfung kann beispielsweise im Zusammenhang mit der Sicherstellung der Interferenz-Freiheit, d. h. gegenseitiger
Nichtbeeinträchtigung der Funktionsfeatures im Zielgerät 3, implementiert sein. Insbesondere kann dabei also sichergestellt werden, dass für die Homologation nichtrelevante Funktionsfeatures auch tatsächlich die Typgenehmigung des existierenden Zielgeräts 3 nicht beeinträchtigen. Für Funktionsfeatures, die jedoch homologationsrelevant (z. B. bezüglich der Emissionsgesetzgebung für Kraftfahrzeuge) sind, muss vor deren Implementierung gegebenenfalls eine erforderliche Typgenehmigung im Wege eines Änderungsantrages bei einer geeigneten Prüfungsorganisation erfolgen.
Damit ein in der Feature-Development-Plattform 1 a gestaltetes Funktionsfeature im Feature-Store 1 b vom Endanwender 11 gefunden und ausgewählt werden kann und damit es von einem Endgerät wie einem Head-Unit-Display, einem Tablet 17 oder einem Smartphone 18 bedienbar ist, können in einem weiteren in der Feature-Development-Plattform 1 a implementierten Schritt Q9 der Fig. 3 graphische Elemente wie "Icons" oder Graphical-User-Interfaces (GUI) für anzubietende Funktionsfeatures bereitgestellt werden. Ferner kann in einem weiteren in der Feature-Development-Plattform 1 a implementierten Schritt Q10 der Fig. 3 ein Verrechnungsmodell zur Bezahlung des anzubietenden
Funktionsfeatures bereitgestellt werden.
In Fig. 7 sind die oben anhand der Figuren 3 bis 6 beschriebenen Feature- Entwicklungsschritte in der Feature-Development-Plattform 1a von der hersteller- und benutzerseitigen Feature-Modellierung Q1 mit der herstellerseitigen
Schnittsteilen-Bereitstellung und benutzerseitigen Schnittsteilen-Auswahl Q2 sowie der herstellerseitigen Bereitstellung Q3 der übrigen Daten über die
Software- und Hardware-Architektur des Zielgeräts 3, über die Code-Erstellung Q4 für das vom Benutzer 10 modellierte/entworfene Funktionsfeature bis hin zur Simulation Q5 des erstellten Feature-Codes zur Optimierung Q6 des
Funktionsfeatures und Prüfung Q7-Q8 der Erfüllung der vorbestimmten technischen Anforderungen nochmals veranschaulicht.
In Fig. 7 sind insbesondere die hersteiler- oder providerseitige Bereitstellung der Zielgeräte-Schnittstellen 12, der durch die formalisierte Wirkkettenbeschreibung erlaubten Wirkketten-Modifikationen 13 sowie der davon abhängigen Standard- Wirkketten 14 (herstellerseitiges Feature-Modell) mit vorbestimmten Gestaltungs- Eingriffsstellen für den Benutzer 10 schematisch veranschaulicht. Weiterhin sind ein vom Benutzer 10 der Fig. 3 daraus individuell gestaltete Feature-Modell 15 sowie ein herstellerseitig bereitgestelltes Simulationsmodell 16 der restlichen Zielsteuergeräte-Ausstattung zur Simulation des vom Benutzer 10 gestalteten Funktionsfeatures schematisch angedeutet. Bei den Feature-Modellen 14 und 15 können dabei A und B insbesondere Eingangsparameter sowie C und D
Ausgangsparameter einer Wirkkette oder deren einzelner Wirkzusammenhänge oder auch innerhalb von Wirkzusammenhängen bezeichnen und z. B. oben beschriebene Wirk- und Zielparameter des jeweiligen Funktionsfeatures darstellen.
Nun wird ein Feature-Integration-Framework 4 der hierin dargelegten Art mit Bezug auf Figuren 1 und 9 bis 14 erläutert.
Damit in einen Funktionsverbund des Zielgeräts 3 der Fig. 1 ein neues physikalisches Funktionsfeature eingebunden werden kann, ist in seinem
Zielsteuergerät 2 das Feature-Integration-Framework 4 der hierin dargelegten Art vorgesehen, das zum Integrieren des neuen Funktionsfeatures ausgebildet ist. Figur 9 illustriert in einer schematischen Darstellung ein Beispiel der Software- Architektur eines solchen Feature-Integration-Frameworks 4 in einem
entsprechenden Zielsteuergerät 2. Die Figur 10 zeigt das Feature-Integration- Framework 4 der Figur 9 nochmals separat.
Bei der nachfolgenden Beschreibung des Feature-Integration-Frameworks 4 werden die oben bei der Beschreibung des Feature-Development-Frameworks 1 erläuterten Hilfsbegriffe zur Definition eines Funktionsfeatures als eines
Wirkzusammenhangs oder mehrerer eine Wirkkette bildender
Wirkzusammenhänge von Wirk- und Zielparametern des Zielgeräts 3 verwendet. Das Feature-Integration-Framework 4 der Figur 9 ist dazu ausgebildet, die beispielsweise im Feature-Preparator 6 der Feature-Development-Plattform 1a der Figur 1 vom Benutzer 10 ausgewählten Wirkparameter des Zielgeräts 3 bereitzustellen und die Zielparameter des Zielgeräts 3 entsprechend den
Vorgaben des neu integrierten Funktionsfeatures zu verändern.
Das Feature-Integration-Framework 4 der Fig. 9 und 10 umfasst rein beispielhaft folgende Elemente: einen LightWeight-Hypervisor (LWHVR), ein Virtual-Machine- Interface (VMI), mindestens einen Virtual-Machine-Adapter (VMA), einen
Feature-Proxy-on-Device (FPoD) und einen Feature-Coordinator-on-Device (FCoD), die nachfolgend jeweils einzeln und in ihrer Zusammenwirkung miteinander im Zielsteuergerät 2 der Fig. 9 beschrieben werden. Es sei angemerkt, dass ein Feature-Integration-Framework der hierin
dargelegten Art keinesfalls zwingend alle der in Fig. 10 gezeigten vier
verschiedenen Elemente VMI, VMAs, FPoD und FCoD umfassen muss. Vielmehr kann es sich beim Feature-Integration-Framework um ein einzelnes oder eine beliebige Kombination einiger dieser vier Elementarten handeln, die z. B. als Nachrüstsoftware im existierenden Zielsteuergerät 2 installierbar sind. Zum anderen können die nachfolgend beschriebenen beispielhaften Funktionalitäten und Eigenschaften dieser einzelnen Elemente auch zum Teil anders
untereinander verteilt oder zusammengefasst sein, um das Hosten eines neuartigen Funktionsfeatures im Zielsteuergerät 2 in der hierin dargelegten Art und Weise zu ermöglichen.
Für neue, d. h. nachträglich geladene Funktionsfeatures kann insbesondere automatisch sichergestellt werden, dass die übrige Funktionalität des Zielgeräts 3 nicht beeinträchtigt wird. Hierzu kann beispielsweise die Freiheit von
Interferenzen (Freedom-of-lnterference) zwischen der nachgeladenen Software und der bereits vorhandenen Software im Zielsteuergerät 2 sichergestellt werden. Dies kann im Zielsteuergerät 2 insbesondere mit Hilfe der an sich bekannten Hypervisor-Technologie realisiert sein. Zum Einsatz in einem Zielgerät 3 wie einem Kraftfahrzeug oder einer Arbeits- oder Werkzeugmaschine ist insbesondere ein sogenannter LightWeight-Hypervisor (LWHVR) geeignet, der für Einsätze in Microcontroller-basierten Steuergeräten geeignet ist. Er eignet sich ferner auch für ASIL-relevante Bereiche (Automotive-Safety-Integrity-Level).
Das Konzept zur Nutzung des LWHVRs kann insbesondere darin bestehen, dass auf einem Master-Core (Core 0) des Zielsteuergeräts 2 ein Betriebssystem (OS), wie z. B. RTA-OS, sowie für den Betrieb wichtige Master-Software, wie z. B. AUTOSAR und andere sicherheitsrelevante Software, laufen. Auf anderen Cores (allgemein eine beliebige Anzahl: Corel bis Core n; in Fig. 9: Core 1 , Core 2 und Core 3) laufen voneinander bezüglich der Laufzeit, der Speicherzugriffe etc. unabhängige weitere Software-Anwendungen (auch als Guest-S oftware bezeichnet) innerhalb von einer oder mehreren Virtuellen Maschinen (allgemein eine beliebige Anzahl: VM1 bis VMx; in Fig. 9: VM1 , ... VMm, ... VMy). Gemäß der Logik des LWHVR dürfen die Master-Software und die Virtuellen Maschinen nur über die sogenannte Shared-Memory kommunizierten; dementsprechend können sie gegenseitig weder Funktionen des anderen aufrufen noch auf Variablen des anderen zugreifen.
Das Virtual-Machine-Interface (VMI) der hierin dargelegten Art ist dazu ausgebildet, dies auf der Seite der Master-Software (vgl. Fig. 9) zu überbrücken, um so auf den Virtuellen Maschinen (VM1 , ... VMm, ... VMy) laufenden neuartigen Funktionsfeatures den Zugriff auf ohne den VMI nur der Master- Software zugängliche Informationen, wie z. B. Ein-/Ausgänge eines Systems im Zielsteuergerät 2 oder Zielgerät 3, zu erlauben. Mit anderen Worten ist der VMI dazu ausgebildet, einen kontrollierten Zugang für auf den Virtuellen Maschinen laufende Guest-Software auf eine Peripherie des Systems über die Master- Software bereitzustellen oder durchzuführen. Dadurch kann insbesondere einem als Guest-Software nachträglich geladenen Funktionsfeature ein Zugriff auf Wirk- und Zielparameter des Zielgeräts 3 ermöglicht werden, die sonst nur der Master- Software zugänglich sind.
Ein Virtual-Machine-Adapter (VMA) ist das Gegenstück des VMI auf jeder Virtuellen Maschine (VM1 , ... VMm, ... VMy). Die auf der jeweiligen Virtuellen Maschinen laufende Guest-Software ist agnostisch gestaltet, d. h.
infrastrukturunabhängig; sie kann also Funktionsaufrufe der Master-Software, wie z. B. Ein-/Ausgabe-Zugriffe (Input/Output), enthalten. Der VMA ist dazu ausgebildet, diese Aufrufe aufzufangen und dem VMI zu übergeben, welches dann die entsprechenden Anforderungen an die Master-Software weiterleitet, und umgekehrt. Dadurch kann also insbesondere einem als Guest-Software nachträglich geladenen Funktionsfeature ein Zugriff auf Wirk- und Zielparameter des Zielgeräts 3 ermöglicht werden, die sonst nur der Master-Software zugänglich sind.
Der Feature-Proxy-on-Device (FPoD) ist dazu ausgebildet, Eingriffspunkte (Ziel- und Wirkparameter) im Zielgerät 3 in den technisch und rechtlich zulässigen, beispielsweise mittels des Feature-Preparators 6 der Feature-Development- Plattform 1 a der Fig. 1 individuell gestalteten Wirkketten bereitzustellen. Damit bildet der FPoD eine Art Bypass-Funktionalität in der Master-Software, wie in Fig. 1 1 veranschaulicht. Fig. 1 1 zeigt in einem schematischen Blockschaltbild ein Beispiel im FPoD implementierter Ausführungsschritte für ein neues Funktionsfeature des
Zielgeräts 3. In einem Verbindungschritt Q1 1 wird ein Aufruf zum Auslesen und/oder Verändern eines Ziel- oder Wirkparameters des Zielgeräts 3 gemäß der Definition des neuen Funktionsfeatures erhalten, beispielsweise vom VMI. In einem Zulassungsschritt Q12 wird geprüft, ob das neue Funktionsfeature oder die dadurch zu veranlassende Ziel- oder Wirkparameteränderung zulässig ist.
Nur wenn auch dies erfüllt ist (in Fig. 1 1 durch &-Zeichen angedeutet), erfolgt in einem weiteren Schritt Q13 eine Zugangserlaubnis oder Aufforderung an die Guest-Software, woraufhin diese in einem Schritt Q16 beispielsweise einen vom Funktionsfeature berechneten Parameterwert bereitstellt. Das erfolgt in Fig. 11 durch das Umlegen eines symbolischen Schalters 19 in den entsprechenden unteren Strang (nicht gezeigt, d. h. der Logikgatter der Fig. 11 ist in seiner Ruhestellung dargestellt). In einem weiteren Schritt Q15 kann der bereitgestellte Parameterwert gemäß der Feature-Definition zur Veränderung der Wirk- oder Zielparameter im Zielgerät 3 verwendet werden. Ist der Schalter 19 nicht aktiv (Ruhestellung wie in Fig. 1 1 gezeigt), d. h. in den oberen Strang geschaltet, kann dort gemäß dem im Schritt Q11 erhaltenen Aufruf beispielsweise in einem Schritt Q14 ein Parameterwert von der Master-Software zugeführt werden, der dann im Schritt Q15 im Zielgerät 3 weiterverwendet wird.
Die im obigen Zulassungsschritt Q12 überprüfte technische und rechtliche Zulässigkeit eines über den FPoD im Funktionsverbund des Zielgeräts 3 zu integrierenden Funktionsfeatures kann z. B. in der Erfüllung mindestens einer der vorbestimmten technischen Anforderungen der hierin dargelegten Art bestehen. Eine entsprechende Prüfung kann insbesondere im FPoD selbst implementiert sein.
Dabei kann der FPoD zusätzlich dazu ausgebildet sein, zentrale oder
entscheidende Wirkzusammenhänge der neu integrierten Funktionsfeatures, die z. B. die Sicherheit des Zielgeräts 3 oder seine abgas- oder
energieverbrauchsrelevante Funktionen betreffen, zu überwachen. Dadurch kann wiederum die funktionale Integrität eines Gesamtsystems des Zielgeräts 3 sichergestellt werden. Auch eine derartige Überwachung kann vom obigen Zulassungsschritt Q12 der Fig. 1 1 umfasst sein, insbesondere auch zur Laufzeit des Funktionsfeatures.
Für derartige Überwachungs- und/oder Prüfungszwecke kann der FPoD beispielsweise dazu ausgebildet sein, das im Feature-Preparator 6 der Fig. 1 definierte Feature-Verhalten z. B. durch Constraint-Graphs zu modellieren und/oder ein solches Modell zur Überwachung der Wirkzusammenhänge der neu integrierten Funktionsfeatures zu nutzen. Auf diese Weise kann beispielsweise die Nichtverletzung von vorbestimmten zulässigen Wertebereichen innerhalb von Wirkketten oder auch ein erwartetes prinzipielles Verhalten zwischen den betroffenen Wirk- und Zielparametern durch den FPoD geprüft oder zur Laufzeit des Features überwacht werden.
Der Feature-Coordinator-on-Device (FCoD) kann insbesondere einen der zentralen Elemente des Feature-Integration-Frameworks 4 der hierin dargelegten Art darstellen. Er kann beispielsweise auf Basis der von den Funktionsfeatures verwendeten Schnittstellen im Zielgerät 3 sowie den Abhängigkeiten zwischen den Funktionsfeatures automatisch im Zielsteuergerät 2 generiert werden.
Dabei kann im FCoD insbesondere die Sicherstellung, Prüfung und/oder Überwachung der Erfüllung mindestens einer der vorbestimmten technischen Anforderungen der hierin dargelegten Art implementiert sein. Insbesondere kann dadurch berücksichtigt sein, dass bestimmte Funktionsfeatures auf anderen Funktionsfeatures aufbauen können, wie z. B. dass Distance-Control Cruise- Control voraussetzt. Ferner kann insbesondere für oben erwähnte MultiCore- Systeme eine geeignete Reihenfolge sowie Parallelisierbarkeit von
Funktionsfeatures bei der Generierung des FCoD berücksichtigt sein oder werden. Die Reihenfolge und/oder Parallelisierbarkeit von Funktionsfeatures können statisch innerhalb von Wirkketten implementiert sein oder aber alternativ oder zusätzlich zur Laufzeit der Funktionsfeatures aktiviert oder deaktiviert werden. Es kann beispielsweise implementiert sein, dass im Falle eines Ausfalls eines Funktionsfeatures (z. B. Cruise-Control) zur Laufzeit ein davon abhängiges Funktionsfeature (z. B. Distance-Control) deaktiviert oder seine betroffenen Schnittstellen, wie z. B. Wirk- oder Zielparameter, mit geeigneten Ersatzwerten versorgt werden. Letzteres ist in Fig. 12 schematisch dargestellt: Figur 12 zeigt ein schematisches Blockschaltbild eines Beispiels in einem FCoD der hierin dargelegten Art implementierter Überwachungsschritte für ein neues Funktionsfeature des Zielgeräts 3 während der Feature-Laufzeit. In einem Kontrol Isch ritt Q16 wird geprüft, ob das Funktionsfeature und die Virtuelle Maschine, auf der es läuft, in Bezug auf vorbestimmte technische
Anforderungen, insbesondere das Vorhandensein benötigter Schnittstellen und anderer Funktionsfeatures im Zielgerät 3, ordnungsgemäß funktionieren. Ist dies der Fall, ist ein symbolischer Schalter 20 in seinen unteren Strang geschaltet (diese Position ist in Figur 12 nicht gezeigt), wodurch in einem Eingabeschritt Q17 ein aktueller Ausgangswert X eines gemäß der Feature-Definition benötigten anderen Funktionsfeatures von der Virtuellen Maschine erhalten wird. Der erhaltene Ausgangswert X wird in einem weiteren Schritt Q18 gemäß der Feature-Definition weiterverwendet, z. B. zu einer entsprechenden Änderung eines Wirk- oder Zielparameters des Zielgeräts 3 an den VMI weitergegeben. Wird hingegen im Kontrollschritt Q16 ein Ausfall des benötigten anderen
Funktionsfeatures festgestellt, ist der Schalter 20 gemäß Fig. 12 in seinen oberen Strang geschaltet, in dem in einem Ersatzschritt Q19 ein geeigneter Ersatzwert für den Ausgangswert X erhalten und im Schritt Q18 weiterverwendet wird.
Um ein oben beschriebenes funktional überwachtes Laufen der
Funktionsfeatures sicherzustellen, kann der FCoD beispielsweise dazu ausgebildet sein, abstraktere Bobachtermodelle (z. B. durch Verwendung einer formalisierten Wirkkettenbeschreibung, z. B. mittels eines Constraint-Graphen etwa wie in Figur 6) anhand der beispielsweise im Feature-Preparator 6 der Feature-Development-Plattform 1 a der Figur 1 ausgewählten und/oder festgelegten Feature-Freiheitsgraden innerhalb von Wirkketten zu generieren. Unter Verwendung derartiger Bobachtermodelle kann der FCoD dazu
ausgebildet sein, Fehlerdiagnosen und/oder Überwachung von neu gestalteten Funktionsfeatures durchzuführen und so bei Bedarf z. B. Ersatzwerte für ausgefallene (Teil-)Features wie in Figur 12 bereitzustellen. Auf diese Weise kann ein reibungsloses Funktionieren der übriggebliebenen Funktionsfeatures in einem Funktionsverbund des Zielgeräts 3 sichergestellt werden. Figur 13 veranschaulicht in einem schematischen Diagramm ein Beispiel eines derartigen Beobachtermodells, das in einem FCoD der hierin dargelegten Art automatisch generiert und zur Überwachung eines neu gestalteten
Funktionsfeatures des Zielgeräts implementiert ist. Im Beobachtermodell der Figur 13 sind folgende Merkmale implementiert:
- automatisches Erzeugen einer Referenzfunktion 21 gemäß dem vom
Benutzer 10 individuell gestalteten Feature-Modell 15 (vgl. Figur 7);
- dynamisches Laufen der Referenzfunktion 21 und automatischer Vergleich durch Bildung einer Verlaufsdifferenz 23 (in Figur 13 auch als D bzw. deren zeitliche Ableitung M symbolisiert) zwischen der Referenzfunktion 21 und der tatsächlich implementierten Feature-Funktion 22; und
- Bildung einer nach vorbestimmten Regeln von der Verlaufsdifferenz 23 abhängigen Summe S in einem Schritt Q20 und einer nach vorbestimmten Regeln von der Verlaufsdifferenz 23 und einem geeigneten zusätzlichen Abweichungsparameter e abhängigen Abweichung d in einem Schritt Q21 und Sicherstellung anhand der so gebildeten Werte der Summe S und der Abweichung d, dass die tatsächlich implementierte Feature-Funktion 22 den vorbestimmten technischen Anforderungen genügt.
Wie in Figur 7, kann in Figur 13 bei der Erzeugung der Referenzfunktion 21 sowie der tatsächlich implementierten Feature-Funktion 22 jeweils ein
Simulationsmodell 16 der restlichen Zielsteuergeräte-Ausstattung verwendet werden. Ebenfalls wie in Fig. 7 können bei den Modell-Funktionen 21 und 22 A und B insbesondere Eingangsparameter sowie C und D Ausgangsparameter einer Wirkkette oder deren einzelner Wirkzusammenhänge oder auch innerhalb von Wirkzusammenhängen bezeichnen, die z. B. oben beschriebene Wirk- und Zielparameter des jeweiligen Funktionsfeatures sein können.
Ferner kann der FCoD dazu ausgebildet sein, die unter seiner Kontrolle befindlichen Funktionsfeatures zu schedulen (d. h. deren
Abarbeitungsreihenfolge untereinander zu planen), zu starten und/oder auch zu stoppen. Weiterhin kann der FCoD dazu ausgebildet sein, für eine
Datenkonsistenz innerhalb und zwischen den Wirkketten zu sorgen. Dies kann beispielsweise anhand der im Feature-Preparator 6 der Fig. 1 festgelegten Freiheitsgraden, insbesondere in Bezug auf die Reihenfolge und Parallelisierbarkeit von Wirkzusammenhängen sowie das Scheduling, realisiert sein.
Figur 14 zeigt in einem schematischen Blockdiagramm eine mögliche
Kommunikationsbeziehung des FCoD zu den anderen oben beschriebenen Elementen des Feature-Integration-Frameworks 4 der hierin dargelegten Art, insbesondere wie in Fig. 9. Dabei kennzeichnen die Pfeile die Richtung der Weitergabe der Wirk- und Zielparameter zwischen einer Virtuellen Maschine VMm, auf der ein neues Funktionsfeature 24 als Guest-S oftware läuft, und der auf dem Master-Core (vgl. Fig. 9) des Zielsteuergeräts 2 laufenden Master- Software (Master-SW). Wie in Fig. 9 und 14 angedeutet, können das VMI und der FPoD in der Software-Architektur des Zielsteuergeräts 2 insbesondere auf der Seite der Master-Software installiert/installierbar sein, d. h. in einem privilegierten Bereich 25, der dem Master-Core und der Master-Software zugeordnet ist.
Zusammenfassend wird anhand der Fig. 2 eine mögliche Schrittabfolge von der individuellen Feature-Gestaltung durch einen Benutzer 10 eines Feature- Development-Frameworks 1 der hierin dargelegten Art bis zum Aussuchen und Implementieren eines solchen individuell gestalteten Funktionsfeatures in einem Zielgerät 3 durch einen Endanwender 11 , z. B. einen Fahrer des Kraftfahrzeugs, und einer Überwachung des neuen Funktionsfeatures zu dessen Laufzeit unter Einsatz eines Feature-Integration-Frameworks 4 der hierin dargelegten Art beschrieben. Dabei kann es sich insbesondere um das in Fig. 1 und 3 bis 8 dargestellte Feature-Development-Framework 1 und das in Fig. 1 und 9 bis 14 dargestellte Feature-Integration-Framework 4 handeln.
Insbesondere können dabei in einer Vorbereitungsphase (nicht gezeigt), die der individuellen Feature-Gestaltung durch den Benutzer 10 vorausgehen kann, das Feature-Development-Framework 1 und das Zielsteuergerät 2 ausgerüstet werden, indem
- im Rahmen eines Verfahrens der hierin dargelegten Art zur Erstellung des Feature-Development-Frameworks 1 für bereits im Zielgerät 3 implementierte oder neue Wirkketten/Funktionsfeatures an
vorbestimmten Gestaltungs-Eingriffsstellen zulässige Modifikationen beschrieben werden, die dem Benutzer 10 in der Feature-Development- Plattform 1a zur individuellen Feature-Gestaltung bereitgestellt, d. h. erlaubt sein sollen:
o diese können z. B. mit Hilfe von Constraint-Graphs und zusätzlichen Attributen beschrieben werden, wobei o als vorbestimmte technische Anforderungen unter anderem
folgende Restriktionen und Implementierungsanforderungen berücksichtigt sein können:
■ Angaben, welche Funktionsfeatures unbedingt auf dem gleichen Core laufen müssen oder aber nicht auf dem gleichen Core laufen dürfen;
■ maximale Ressourcenanforderungen, wie Speicherbedarf - RAM, Flash - Echtzeitanforderungen, Laufzeitbedarf, Jitter, Latenzzeiten etc. im Zielsteuergerät 2;
■ qualitative Anforderungen wie ASIL (Automotive-Safety- Integrity-Level) und dergleichen;
- das Zielsteuergerät 2 durch Installation des Feature-Integration-
Frameworks 4 so vorbereitet wird, dass weitere, insbesondere neuartig gestaltete Funktionsfeatures hinzugefügt und bereits implementierte Funktionsfeatures insbesondere auf neuartige Weise verändert werden können, wobei
o ein Hypervisor, insbesondere ein oben beschriebener
LightWeight-Hypervisor (LWHVR), bereits im Zielsteuergerät 3 integriert sein kann; und/oder
o beispielsweise ein Feature-Coordinator-on-Device (FCoD) als Feature-Integration-Framework 4 installiert werden kann, damit die zulässigen Ziel- und Wirkparameter des Zielgeräts 3 für die Feature-Entwicklung bzw. -Durchführung verfügbar sind.
Es sind nun folgende in Figur 2 veranschaulichte Schritte möglich, die teilweise oben im Detail anhand der Figuren 3 bis 14 einzeln beschrieben wurden:
Schritt I: Zugang zur Cloud-basierten Feature-Development-Plattform 1 a über einen PC oder ein mobiles Endgerät - Der Benutzer 10 logt sich über ein Endgerät 26, insbesondere ein Smartphone oder einen PC, im Feature-Development-Framework 1 ein und bekommt dadurch die Feature-Development-Plattform 1 a, d. h. eine Web-User-Interface-Umgebung, bereitgestellt, mit der er sein
gewünschtes Funktionsfeature individuell gestalten kann.
- Hierzu wählt er für das Funktionsfeature aus einer bereitgestellten Liste von Schnittstellen (z. B. Wirk- und Zielparameter) die physikalischen Ein- und Ausgangsgrößen beim Schritt Q2 der Fig. 3.
Schritt II: Entwicklung eines neuen Funktionsfeatures mittels der Feature- Development-Plattform 1a
- Aus den gewählten Schnittstellen wird ein Modelskeleton gebaut (eine modifizierbare Standard-Wirkkette 14 der Figur 7 gemäß den Schritten Q1 , Q3 der Figur 3), in dem der Benutzer 10 an den bereitgestellten Gestaltungs-Eingriffsstellen durch erlaubte Modifikationen der Standard- Wirkkette 14 seine individuelle Funktionalität einbaut und damit ein benutzerseitig gestaltetes Feature-Modell 15 der Figur 7 erhält.
- Aus dem benutzerseitig gestalteten Feature-Modell 15 wird im Schritt Q4 der Figuren 3 und 7 ein Software-Code generiert, welcher dann kompiliert und gelinkt wird.
- Zusätzlich kann dieser Software-Code beispielsweise in den Schritten Q5-Q7 der Figuren 3, 7 und 8 simuliert und getestet werden.
- Des Weiteren kann beispielsweise an dieser Stelle basierend auf dem benutzerseitigen Feature-Modell 15 der Figur 7 und den verwendeten Schnittstellen sowie gegebenenfalls den vom Benutzer 10 zuvor festgelegten möglichen (d. h. weiterhin verbleibenden)
Modifikationen/Freiheitsgraden in den Wirkketten der Feature- Coordinator-on-Device (FCoD) der Figuren 9-14 im Zielsteuergerät 2 automatisch generiert werden.
Schritt III: Vorbereitung des entwickelten Funktionsfeatures auf dessen
Implementierung im Zielgerät 3
- Hier kann beispielsweise in dem Feature-Development-Kit 7 und/oder in dem Feature-Deployment-Checker 8 der Feature-Development-Plattform 1 a in den Schritten Q5 bis Q8 der Figur 3 geprüft werden, ob das korrekte Einfügen des Funktionsfeatures in die Wirkkette des Zielgeräts 3 erfolgt ist. Dazu kann an dieser Stelle beispielsweise
o eine optimale Verteilung von Wirkzusammenhängen in einer
Wirkkette geprüft werden;
o im Hinblick auf MultiCore-Systeme simuliert und dann festgelegt werden, welche Funktionsfeatures (Wirkketten bzw. Teile davon) parallelisierbar sind, um eine volle Performance (bzgl. Core-Balancing) zu erhalten; o die Zuordnung der Funktionsfeatures zu bestimmten Cores geprüft
werden (d. h. ob die Funktionsfeatures in den vorgegebenen Core- Konfigurationen laufen);
o ebenfalls die Ressourcenanforderungen der Funktionsfeatures, wie
Speicherbedarf - RAM, Flash - Echtzeitanforderungen, Laufzeitbedarf, Jitter, Latenzzeiten etc. im Zielsteuergerät 2 geprüft werden.
Schritt IV: Erwerb des neu gestalteten Funktionsfeatures im Feature-Store 1 b durch den Endanwender 1 1
- Wenn ein Endanwender 11 sich von einem Endgerät 18, beispielsweise einem Smartphone, im Feature-Development-Framework 1 einloggt und im Feature-Store 1 b der Fig. 1 ein neues (beispielsweise vom Benutzer 10 gestaltetes) Funktionsfeature auswählt, kann im Hintergrund (im Feature-Development-Framework 1 ) eine Prüfung implementiert sein, ob das ausgewählte Funktionsfeature sich mit hinter seiner Endanwender-ID registrierten Konfigurationen des Zielgeräts 3 verträgt. Abhängig vom Ergebnis dieser Prüfung (Ja/Nein) kann an dieser Stelle beispielsweise: o Fall "Ja": eine Liste der entsprechenden Konfigurationen angezeigt werden;
o Fall "Nein": der Endanwender 11 aufgefordert werden, eine
passende Konfiguration anzulegen, bzw. eine Hilfestellung bereitgestellt werden, wie eine solche Konfiguration angelegt werden kann.
Schritt V: Download des erworbenen Funktionsfeatures zum Zielsteuergerät 2
- Falls unter Schritt IV eine geeignete Konfiguration des Zielgeräts 3
festgestellt worden ist, wird das ausgewählte Funktionsfeature (z. B. als ein Software-Paket) an das Zielsteuergerät 2 bzw. an dessen zur Installation des Funktionsfeatures ausgebildete Einheit, wie eine
CCU/CGW mit dem Feature-Integration-Framework 4 der Figur 1 , übertragen, die dann die Installation des Funktionsfeatures im
Zielsteuergerät 2 vornimmt. Dabei steht CCU für eine Connected-Control- Unit und CGW für ein Central-Gate-Way, also ein Steuergerät, das eine Verbindung zur Cloud 5 hat.
Schritt VI: Überwachung des im Zielsteuergerät 2 installierten neuen
Funktionsfeatures
- Das Funktionsfeature ist nun im Zielsteuergerät 2 installiert, und es kann insbesondere eine weitere Kommunikation zwischen dem Zielgerät 3, der von diesem entfernten IT-Infrastruktur 5 (Cloud) und dem Endanwender
1 1 erfolgen, z. B. mittels einer mobilen Anwendungssoftware 27 (Mobile App) auf dem Endgerät 18 des Endanwenders 11.
- Insbesondere kann beim Aktivieren des Funktionsfeatures automatisch ein FCoD der Figur 9-14 aktiviert werden, der auch zum Überwachen des gestarteten Funktionsfeatures ausgebildet sein kann, indem er z. B. dafür sorgt, dass selbst beim Ausfallen von Teilen der Funktion des Features dieses dennoch funktional weiterlaufen kann, indem es etwa mit geeigneten Ersatzwerten, wie z. B. in Bezug auf Figur 12 beschrieben, versorgt wird.
- Alternativ oder zusätzlich kann es mittels des FCoD implementiert sein, dass ein geeignetes Beobachtermodell, wie z. B. in Bezug auf Figur 13 beschrieben, zur Sicherstellung der Erfüllung mindestens einer der vorbestimmten technischen Anforderungen läuft, das beispielsweise mit Hilfe von Constraint-Graphs gebildet sein und dafür sorgen kann, dass vorbestimmte Grenzwerte oder Funktionsverläufe in bestimmten
Wirkketten nicht über- oder unterschritten werden.

Claims

Ansprüche
1. Feature-Development-Framework (1 ) zur benutzerseitigen Entwicklung
physikalischer Funktionsfeatures eines Zielgeräts (3), insbesondere eines Kraftfahrzeugs oder einer Arbeits- oder Werkzeugmaschine, umfassend:
eine computergestützte Umgebung (Feature-Development-Plattform 1a), die eine Feature-Entwickler-Software und von dieser gesteuerte
Zugriffsmechanismen auf Hardware-Ressourcen im Zielgerät (3) und in einer von diesem entfernten IT-Infrastruktur (5) aufweist,
wobei die Feature-Entwickler-Software einem Benutzer (10) für mindestens ein im Zielgerät (3) implementierbares physikalisches Funktionsfeature mindestens eine vorbestimmte Gestaltungs- Eingriffsstelle zu dessen jeweils qualitativ unterschiedlicher Gestaltung bereitstellt, und
wobei die technischen Auswirkungen der durch die mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle bereitgestellten
Gestaltungsmöglichkeiten des mindestens einen Funktionsfeatures auf das Zielgerät (3) mindestens einer vorbestimmten technischen Anforderung genügen.
2. Feature-Development-Framework (1 ) nach Anspruch 1 , wobei die mindestens eine vorbestimmte technische Anforderung eine oder mehrere der folgenden Anforderungen umfasst:
Nichtbeeinträchtigung anderer physikalischer Funktionsfeatures im Zielgerät (3);
Einhaltung rechtlicher Zulassungsbedingungen für das Zielgerät (3); Einhaltung vorbestimmter Ressourcenanforderungen an die Hardware und/oder Software im Zielgerät (3);
Einhaltung einer vorbestimmten Core-Zuordnung bei einem MultiCore- System in einem Zielsteuergerät (2).
3. Feature-Development-Framework (1 ) nach Anspruch 1 oder 2, wobei mindestens eines der mittels der Feature-Entwickler-Software gestaltbaren Funktionsfeatures eine an der mindestens einen vorbestimmten Gestaltungs- Eingriffsstelle modifizierbare Wirkkette (W1 , W2, W3, W5) von
Wirkzusammenhängen zwischen eine physikalische Feature-Funktionalität im Zielgerät (3) betreffenden Wirk- und Zielparametern darstellt und/oder mindestens einen an der mindestens einen vorbestimmten Gestaltungs- Eingriffsstelle modifizierbaren Wirkzusammenhang innerhalb einer solchen Wirkkette (W1 , W2, W3, W5) umfasst.
4. Feature-Development-Framework (1 ) nach einem der vorhergehenden
Ansprüche, wobei die Feature-Entwickler-Software eine Simulationssoftware zur Optimierung mindestens eines der mittels der Feature-Entwickler-Software gestaltbaren Funktionsfeatures hinsichtlich der Hardware-Ressourcennutzung und/oder Wirksamkeit und/oder Zeitausnutzung bei der Implementierung des Funktionsfeatures im Zielgerät (3) und/oder zur Prüfung der Einhaltung mindestens einer der vorbestimmten technischen Anforderungen umfasst.
5. Feature-Development-Framework (1 ) nach einem der vorhergehenden
Ansprüche, wobei mindestens eines der in der Feature-Entwickler-Software gestaltbaren Funktionsfeatures mittels einer formalisierten Methodik und eines geeigneten Software-Werkzeugs definiert ist, die sicherstellen, dass dem Benutzer nur zulässige Modifikationen an den vorbestimmten Gestaltungs- Eingriffsstellen bereitgestellt sind, insbesondere mittels eines Constraint- Graphen.
6. Feature-Development-Framework (1 ) nach einem der vorhergehenden
Ansprüche, wobei die Feature-Development-Plattform (1 a) eine oder mehrere der folgenden Einheiten umfasst:
einen Feature-Preparator (6), der zum benutzerseitigen Entwerfen des mindestens einen Funktionsfeatures ausgebildet ist, indem dem Benutzer (10) das mindestens eine Funktionsfeature samt der jeweiligen vorbestimmten Gestaltungs-Eingriffsstellen zur Verfügung und/oder Auswahl bereitgestellt ist; ein Feature-Development-Kit (7), das zur Aufbereitung des mindestens einen vom Benutzer (10) individuell gestalteten Funktionsfeatures abhängig von dem Zielgerät (3) und/oder zu dessen Optimierung hinsichtlich der Hardware-Ressourcennutzung, Wirksamkeit und/oder Zeitausnutzung bei der Implementierung im Zielgerät (3) und/oder zu dessen Prüfung auf Einhaltung mindestens einer der vorbestimmten technischen Anforderungen ausgebildet ist;
einen Feature-Deployment-Checker (8), der zur Vorbereitung des mindestens einen vom Benutzer (10) gestalteten Funktionsfeatures auf dessen Implementierung im Zielgerät (3) und/oder zu dessen Optimierung hinsichtlich der Hardware-Ressourcennutzung, Wirksamkeit und/oder Zeitausnutzung im Zielgerät (3) und/oder zu dessen Prüfung auf
Einhaltung mindestens einer der vorbestimmten technischen Anforderungen ausgebildet ist;
eine Brokering-Plattform (9), die zum systeminternen und/oder interaktiven Einbeziehen einer individuellen Benutzer-Beratung hinsichtlich einschlägiger Ingenieurs-Dienstleistungen, einer Lizensierung und/oder sonstiger Beratung in den Feature-Entwicklungsprozess ausgebildet ist.
7. Feature-Development-Framework (1 ) nach einem der vorhergehenden
Ansprüche, das ferner ein Endanwender-Front-End Feature-Store (1 b) umfasst, das eine Feature-Erwerbssoftware, die zum Auffinden und Herunterladen des mindestens einen mittels der Feature-Development-Plattform (1 a) entwickelten Funktionsfeatures durch einen Endanwender (11 ) ausgebildet ist, und von dieser gesteuerte Zugriffsmechanismen auf Hardware-Ressourcen im Zielgerät (3) und in der von diesem entfernten IT-Infrastruktur (5) aufweist.
8. Verfahren zur Erstellung eines Feature-Development-Frameworks (1 ) nach einem der vorhergehenden Ansprüche, wobei für das mindestens eine im Zielgerät (3) implementierbare und mittels der Feature-Entwickler-Software benutzerseitig gestaltbare physikalische Funktionsfeature die mindestens eine vorbestimmte Gestaltungs-Eingriffsstelle entworfen, geprüft und bereitgestellt wird, wobei technische Vorgänge, die das mindestens eine Funktionsfeature bei dessen Implementierung im Zielgerät (3) bewirkt, und deren Zusammenwirkungen mit anderen physikalischen Funktionsfeatures im Zielgerät (3) und/oder mit den Hardware-Ressourcen des Zielgeräts (3) und/oder der von diesem entfernten IT-Infrastruktur (5) simuliert werden, wobei für die technischen Auswirkungen der bereitgestellten Gestaltungsmöglichkeiten des mindestens einen Funktionsfeatures auf das Zielgerät (3) die Einhaltung mindestens einer der vorbestimmten technischen Anforderungen getestet wird.
9. Computerprogramm, welches, wenn es in einem Steuergerät oder einer
Datenverarbeitungseinrichtung ausgeführt wird, dazu eingerichtet ist, ein Verfahren nach Anspruch 8 auszuführen.
10. Feature-Integration-Framework (4) zum Integrieren von mittels des Feature- Development-Frameworks (1 ) nach einem der Ansprüche 1 bis 7 individuell gestalteten physikalischen Funktionsfeatures in einem Funktionsverbund eines Zielgeräts (3), insbesondere eines Kraftfahrzeugs oder einer Arbeits- oder Werkzeugmaschine,
wobei das Feature-Integration-Framework (4) in einem Zielsteuergerät (2) installierbar ist, das insbesondere neben einem Master-Core (Core 0), auf dem ein Betriebssystem des Zielsteuergeräts (2) läuft, mindestens einen weiteren Core (Core 1 , ..., Core 3) mit darauf laufenden Virtuellen Maschinen (VM2, ..., VMy) für weitere Software-Anwendungen aufweist, und
wobei das Feature-Integration-Framework (4) eine oder mehrere der folgenden Komponenten umfasst:
ein Virtual-Machine-Interface (VMI), das dazu ausgebildet ist, auf der Seite einer auf dem Master-Core (Core 0) laufenden Master-Software (Master-SW) einen Zugriff auf Systemkomponenten und -Informationen, die dem Master-Core (Core 0) zugeordnet sind, für auf der/den Virtuellen Maschine(n) (VM2, ..., VMy) laufende weitere Software-Anwendungen bereitzustellen;
mindestens einen Virtual-Machine-Adapter (VMA), der jeweils als
Gegenstück des Virtual-Machine-Interface (VMI) auf jeder der Virtuellen Maschinen (VM2, VMy) dazu ausgebildet ist, Funktionsaufrufe einer auf der jeweiligen Virtuellen Maschine (VM2, VMy) laufenden weiteren Software-Anwendung aufzufangen und dem Virtual-Machine-Interface (VMI) zu übergeben;
einen Feature-Proxy-on-Device (FPoD), der dazu ausgebildet ist, den zu integrierenden individuell gestalteten physikalischen Funktionsfeatures den Zugriff auf darin definierte Wirk- und Zielparameter des Zielgeräts (3) bereitzustellen;
einen Feature-Coordinator-on-Device (FCoD), der dazu ausgebildet ist, jedes zu integrierende oder bereits integrierte individuell gestaltete physikalische Funktionsfeature mit den übrigen Hardware- und Software- Ressourcen des Zielgeräts (3) zu koordinieren, insbesondere diese Funktionsfeatures zu schedulen, starten und/oder stoppen.
1 1. Feature-Integration-Framework (4) nach Anspruch 10, bei dem zur
Sicherstellung der funktionalen Integrität des gesamten Funktionsverbunds des Zielgeräts (3) bei der Implementierung der individuell gestalteten physikalischen Funktionsfeatures, insbesondere zur Einhaltung mindestens einer der vorbestimmten technischen Anforderungen,
der Feature-Proxy-on-Device (FPoD) ferner dazu ausgebildet ist, zumindest einige Wirkzusammenhänge der zu integrierenden oder bereits integrierten individuell gestalteten physikalischen Funktionsfeatures vorzugsweise zu deren Laufzeit zu überwachen, insbesondere durch das Modellieren und/oder Simulieren des jeweiligen im Feature-Preparator (6) definierten Feature-Verhaltens; und/oder
der Feature-Coordinator-on-Device (FCoD) ferner dazu ausgebildet ist, zumindest einige der zu integrierenden oder bereits integrierten individuell gestalteten physikalischen Funktionsfeatures, vorzugsweise durch das Generieren abstrakter Beobachtermodelle anhand der jeweiligen im Feature-Preparator (6) definierten Feature-Freiheitsgrade, zu überwachen und/oder bei Fehler oder Ausfall zumindest eines Teils eines oder mehrerer von diesen oder übrigen Funktionsfeatures im Zielgerät (3) Ersatzwerte für ausgefallene Funktionsfeatures oder deren einzelne Teile bzw. Wirk- oder Zielparameter bereitzustellen.
12. Steuergerät (2) zum Steuern eines Funktionsverbunds eines Zielgeräts (3), insbesondere eines Kraftfahrzeugs oder einer Arbeits- oder
Werkzeugmaschine,
wobei das Steuergerät (2) ein Feature-Integration-Framework (4) nach Anspruch 10 oder 11 aufweist.
13. Maschinenlesbares Speichermedium, auf welchem ein Feature-Development- Framework (1 ) nach einem der Ansprüche 1 bis 7 und/oder ein
Computerprogramm nach Anspruch 9 und/oder ein Feature-Integration- Framework (4) nach Anspruch 10 oder 11 gespeichert ist.
PCT/EP2019/060333 2018-05-02 2019-04-23 Feature-development-framework und feature-integration-framework zum implementieren physikalischer funktionsfeatures in einem zielgerät WO2019211122A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018206762.7 2018-05-02
DE102018206762.7A DE102018206762A1 (de) 2018-05-02 2018-05-02 Feature-Development-Framework und Feature-Integration-Framework zum Implementieren physikalischer Funktionsfeatures in einem Zielgerät

Publications (1)

Publication Number Publication Date
WO2019211122A1 true WO2019211122A1 (de) 2019-11-07

Family

ID=66323852

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/060333 WO2019211122A1 (de) 2018-05-02 2019-04-23 Feature-development-framework und feature-integration-framework zum implementieren physikalischer funktionsfeatures in einem zielgerät

Country Status (2)

Country Link
DE (1) DE102018206762A1 (de)
WO (1) WO2019211122A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111124427A (zh) * 2019-11-13 2020-05-08 山东中磁视讯股份有限公司 一种抽取和集成数据的方法、系统及设备

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020212505A1 (de) 2020-10-02 2022-04-07 Ford Global Technologies, Llc Erzeugen eines vereinfachten Modells für XiL-Systeme
DE102020214545A1 (de) 2020-11-18 2022-05-19 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Betreiben eines Steuergeräts eines Nutzfahrzeugs zum Durchführen eines Arbeitsprozesses

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007002658A2 (en) * 2005-06-27 2007-01-04 Ab Initio Software Corporation Managing parameters for graph-based computations
US8204732B1 (en) * 2008-10-03 2012-06-19 The Mathworks, Inc. Modeling communication interfaces for multiprocessor systems
EP2575039A1 (de) * 2011-09-28 2013-04-03 Siemens Aktiengesellschaft Verfahren und Anordnung zur Nutzung einer Ressource einer Hardware-Plattform mit zumindest zwei virtuellen Maschinen
US20140372788A1 (en) * 2013-06-18 2014-12-18 Vmware, Inc. Hypervisor remedial action for a virtual machine in response to an error message from the virtual machine
WO2015103376A1 (en) * 2014-01-06 2015-07-09 Johnson Controls Technology Company Vehicle with multiple user interface operating domains
US20160117158A1 (en) * 2014-10-23 2016-04-28 National Instruments Corporation Global Optimization and Verification of Cyber-Physical Systems Using Floating Point Math Functionality on a System with Heterogeneous Hardware Components

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007002658A2 (en) * 2005-06-27 2007-01-04 Ab Initio Software Corporation Managing parameters for graph-based computations
US8204732B1 (en) * 2008-10-03 2012-06-19 The Mathworks, Inc. Modeling communication interfaces for multiprocessor systems
EP2575039A1 (de) * 2011-09-28 2013-04-03 Siemens Aktiengesellschaft Verfahren und Anordnung zur Nutzung einer Ressource einer Hardware-Plattform mit zumindest zwei virtuellen Maschinen
US20140372788A1 (en) * 2013-06-18 2014-12-18 Vmware, Inc. Hypervisor remedial action for a virtual machine in response to an error message from the virtual machine
WO2015103376A1 (en) * 2014-01-06 2015-07-09 Johnson Controls Technology Company Vehicle with multiple user interface operating domains
US20160117158A1 (en) * 2014-10-23 2016-04-28 National Instruments Corporation Global Optimization and Verification of Cyber-Physical Systems Using Floating Point Math Functionality on a System with Heterogeneous Hardware Components

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111124427A (zh) * 2019-11-13 2020-05-08 山东中磁视讯股份有限公司 一种抽取和集成数据的方法、系统及设备

Also Published As

Publication number Publication date
DE102018206762A1 (de) 2019-11-07

Similar Documents

Publication Publication Date Title
DE102005026040B4 (de) Parametrierung eines Simulations-Arbeitsmodells
DE102017201789B4 (de) Verfahren zum Betrieb eines Kraftfahrzeugs und Kraftfahrzeug
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
WO2019211122A1 (de) Feature-development-framework und feature-integration-framework zum implementieren physikalischer funktionsfeatures in einem zielgerät
DE102011101920A1 (de) Fahrzeugsystemmodellerstellungssysteme und -verfahren
WO2007020231A2 (de) System für den maschinengestützten entwurf technischer vorrichtungen
WO2006066880A1 (de) System und verfahren zum automatischen aktualisieren von funktionalitäten in einem verteilten netzwerk
EP2799983B1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
DE102016119320A1 (de) Verfahren zum Konfigurieren eines realen oder virtuellen elektronischen Steuergerätes
EP2866111B1 (de) Testen eines Steuergerätes mittels einer Testumgebung
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
DE102012101089A1 (de) Verfahren, Geräte und Erzeugnisse zum Testen von Chargenkonfiguration
DE10333087A1 (de) Verfahren zum automatischen Zerlegen von dynamischen Systemmodellen in Teilmodelle
DE102017120016A1 (de) Verfahren zur Konfiguration eines zum Testen eines elektronischen Steuergeräts eingerichteten Testgeräts sowie Konfigurationssystem
DE102017211433A1 (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
DE102018110018A1 (de) Verfahren zum Bereitstellen eines integrierten Prozesses für die Steuergerätentwicklung und Simulationsvorrichtung für die Steuergerätentwicklung
WO2021209192A1 (de) Verfahren und vorrichtung zum prüfen der kompatibilität zwischen einer anwendungssoftware und einer mobilen arbeitsmaschine
DE10324594A1 (de) Verfahren zum Bereitstellen einer verbesserten Simulationsfähigkeit eines dynamischen Systems außerhalb der ursprünglichen Modellierungsumgebung
AT522625B1 (de) Verfahren zur Sicherheitsüberprüfung einer Technikeinheit
WO2002067151A1 (de) Konfigurator
DE102012217328A1 (de) Verfahren zum Simulieren eines Steuergeräts
DE102016123332A1 (de) Virtuelle Inbetriebnahme und Simulation eines Gebäudeautomatisierungssystems
DE102021005309A1 (de) Verfahren zur Bewilligung der Einbringung von Programmcode aus einem Programmcode-Freigabepaket in eine Anwendungsumgebung und informationstechnisches System
DE102016101853A1 (de) Computerimplementiertes Verfahren zur Simulation eines Restbus-Steuergeräteverbundes
EP1983426A1 (de) Automatisierte Visualisierung einer Auswahl von Simulationsdaten

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

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

Country of ref document: EP

Kind code of ref document: A1