EP2526487A1 - Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk - Google Patents

Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk

Info

Publication number
EP2526487A1
EP2526487A1 EP10795250A EP10795250A EP2526487A1 EP 2526487 A1 EP2526487 A1 EP 2526487A1 EP 10795250 A EP10795250 A EP 10795250A EP 10795250 A EP10795250 A EP 10795250A EP 2526487 A1 EP2526487 A1 EP 2526487A1
Authority
EP
European Patent Office
Prior art keywords
soa
connection module
service
network
tsbi
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP10795250A
Other languages
English (en)
French (fr)
Inventor
Egon Mönch
Rainer Klotz
Jeremy Michel
Christoph Prasse
Wolfgang Schmidt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales Deutschland GmbH
Original Assignee
Thales Defence Deutschland 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 Thales Defence Deutschland GmbH filed Critical Thales Defence Deutschland GmbH
Publication of EP2526487A1 publication Critical patent/EP2526487A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Definitions

  • Connection module for connecting at least one sensor, actuator or effector to a service
  • SOA Oriented Architecture
  • the present invention is based on a Service Oriented Architecture (S0A) network.
  • SOA Service Oriented Architecture
  • SOA extends the concept of web services into an architecture for comprehensive and service-based applications, existing systems and applications
  • SOA is known for a wide variety of applications.
  • SOA is an information technology (IT) architecture with flexible
  • sensors integrated in an SOA network can be designed, for example, as cameras for detecting a defined spatial area, as geophones for detecting vibrations or as any other sensors, which information about a spatial area to be monitored, a monitored area
  • Effectors integrated in an SOA network can be embodied as any weapon systems, for example cannons on a tank, but also as jammers, foggers or the like.
  • integrated actuators may be formed as any elements which an input in one
  • an actuator can be designed as an electric motor, an electromagnet or any drive system.
  • sensors, effectors or actuators In order to connect the sensors, effectors or actuators to the SOA network and integrate them into the SOA concept, they must be SOA-capable. For the sake of simplicity, only sensors will be referred to in the following explanations.
  • NetOpFü means being a comprehensive one
  • mission support which extends vertically across all management levels and horizontally across all functional roles to all
  • Involved parties ranging from the individual soldier, to provide the relevant information through the military command levels, the support agencies to the political decision-making levels. Since the armed forces consist of a multiplicity of elements, which in one
  • Integrating, evaluating, condensing, providing and securing information holistically forms the basis for an effective and efficient process
  • Service-oriented architecture is, as the name implies, service-based architecture of a software landscape
  • Service consumer obtains from a pool of single services (service provider) the combination he needs and thus receives quasi-tailor-made IT support. Prerequisite is a precise definition of the individual
  • Orchestration i. the flexible combination of services in the foreground.
  • SOA helps users continuously optimize their business processes, innovate and increase efficiency. However, to truly achieve this, it is imperative to clearly define the processes involved and to ensure the reusability of the services.
  • SOA service oriented architectures
  • Radio systems are included in the information network, these radio systems usually compared to the Wide area networks only a limited bandwidth to
  • SOA service-oriented architecture
  • Component is in this environment the tactical area with its transferable and mobile shares, however plays a key role, especially for the deployment scenarios outlined above, in order to demonstrate the interaction between a service-oriented architecture and the tactical process and the operational value of an SOA in terms of optimal behavior in the framework of the SOA
  • NetOpFü and NNEC NetOpFü and NNEC (NATO Network Enabled Capabilities) is based on the fact that the necessary operational capabilities result from the symbiosis of independent system capabilities.
  • Legacy systems are integrated nationwide.
  • the infrastructure components have not yet reached the maturity level required for use in a (highly) mobile environment.
  • the focus is particularly on the functionalities for the
  • Actuators by means of a suitable connection module to integrate into an SOA environment.
  • a prerequisite is that the sensors or actuators are assigned to a microcontroller and a network interface (a transducer).
  • the publication describes an encapsulation of a sensor or actuator in two layers.
  • a transducer forms an IEEE 1451.x Interface.
  • an IEEE 1451.x communication module capable of communicating with the transducer is integrated into an SOA Web Service.
  • NOSA Open Source Web Architecture
  • SWE Sensor Web Enablement
  • SWE Sensor Web Enablement
  • OAC Open Geospatial Consortium
  • OSGI Open Services Gateway Initiative
  • the present invention therefore has for its object to provide a way in which originally not SOA-enabled sensors can be integrated in a simple and inexpensive way in a SOA network structure.
  • connection module for connecting at least one device to a Service Oriented Architecture (SOA) network, wherein a functionality of the at least one device is depicted as a service in the SOA network.
  • the connection module has at least one first interface for connecting the at least one device and at least one second interface for connecting the SOA network.
  • the connection module has a computing device for
  • Executing a computer program wherein a part of the computer program to be processed is predetermined and another part of the computer program is freely programmable by a manufacturer of the at least one device in order to realize an adaptation of a firmware present on the at least one device to the SOA network.
  • the predetermined part of the computer program is preferably from the manufacturer of the connection module before
  • ROM read only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory programmable read-only memory
  • the memory can be integrated into the computing device (internal memory) or arranged outside the computing device (external memory). After delivery of the connection module to the customer (i.e., the manufacturer of the sensor), the latter may then freely program another part of the computer program and store it on an internal or external memory of the computing device.
  • connection module is also called Tactical Service Bus
  • the TSBI works as one
  • the TSBI provides functionalities as services
  • Interfaces are available as hardware interfaces via which the TSBI is connected to the at least one sensor on the one hand and the SOA network on the other hand.
  • the Interface to the SOA Net zwerk can be formed, for example, as a radio interface, which is controlled for example by a digital signal processor (DSP).
  • DSP digital signal processor
  • the TSBI offers two kinds of interfaces, an SOA interface to the Enterprise Service Buses
  • ESDs Lightweight Service Bus Node
  • LSBN Lightweight Service Bus Node
  • the invention has the advantage that the
  • the present invention is therefore based on the idea of one or more sensors that are not SOA-capable per se
  • Connectivity module provides SOA capability in a simple and cost-effective way to integrate the sensors into a SOA network structure.
  • the integration of the sensors via the connection module is essential
  • An important aspect of the present invention is that a generic encapsulation of arbitrary devices (eg sensors, actuators or effectors) is provided, ie a mapping of any non-SOA capable devices in an SOA environment is made possible .
  • Encapsulation is possible without the manufacturer of the device to be encapsulated having knowledge of the SOA environment and the SOAP (Simple Object Access Protocol).
  • the device manufacturer does not have to
  • the service i.e., SOA webservice
  • SOA webservice basically handles multiple requests as independent transactions; no information is stored between queries.
  • the device to be encapsulated is, for example, a rotatable weapon, it can be rotated to the desired position with a first command and fired with a second command. Now, if one were to discontinue the service corresponding to the second command immediately after the first service, improper processing could result in the weapon being fired even before the desired position is reached.
  • the TSBI connection module provides a remedy by, for example, service requests (so-called requests) can be stored and processed in a coordinated manner. If desired, the connection module may even consider priorities in SOAP requests and in processing the commands
  • a Web service interface (a so-called request-response module) of the connection module generates threads from the SOAP requests and ensures the correct one
  • connection module automatically provides, on request by the user, a suitable WSDL (Web Service Definition Language) file, which is loaded into the registry of the service bus.
  • WSDL Web Service Definition Language
  • Heartbeats allow to know on the SOA level whether an encapsulation is still active and behaving correctly or, for example, is no longer active due to an error.
  • Heartbeat functions are automatically generated for each new encapsulation. These functions are called automatically from time to time. Every successful automatic call of a heartbeat function triggers a new notification (publish), which takes place on the SOA level
  • the device manufacturer has the option to implement the heartbeat function. He makes sure that the sensor / effector, the
  • a watchdog timer will listen for heartbeat messages, and if there are no beartbeat messages, the watchdog timer will trigger a reboot of the responsible heartbeat message
  • connection module be a first Module unit, which maps the connected sensor, effector or actuator as a service in the SOA network, as well as a second module unit, which processes the mapped by the first module unit service over a low-bandwidth radio network while maintaining the SOA functionality.
  • the first module unit is also called Vendor Device Encapsulator (VDE).
  • VDE Vendor Device Encapsulator
  • LSBN Lightweight Service Bus Node
  • the VDE is used to encapsulate any non-SOA enabled device as a web service that is separate from the existing one
  • the VDE generates a service which can be accessed via a request-response module of the VDE (for example in the SOAP) and via a publish / subscribe module of the VDE (for example in JMS format, Java Messaging Service).
  • the VDE hosts the service encapsulation in a closed area of the VDE, the so-called sandbox, which prevents possible malfunctions of the service or the
  • the sandbox also ensures that the intellectual property of the
  • VDE Software and the source code installed by the manufacturer in the TSBI.
  • the VDE offers one
  • the services generated with the VDE are stored in a service registry of the VDE. Depending on the properties and
  • the service registry provides different illustrations or representations (so-called representation) of the service, eg in WSDL, whereby the representation of the service is not necessarily the WS-I (Web Services Interoperability Organization)
  • An LSB Lightweight Service Bus
  • the term LSB does not refer to a device, but to an abstraction of several LSBNs that are networked together.
  • the LSB proposes a service bus adapted to the needs of the military world.
  • connection module known from the IEEE publication "Service-Oriented Sensor Data Interoperability for IEEE 1451 Smart Transducers"
  • the TSBI or VDE does not require that the systems to be encapsulated
  • Transducers are or include such.
  • the invention can provide an SOA interface for any type of system.
  • the TSBI or VDE does not require any particular type of protocol or technology to work with the system
  • the TSBI or the VDE is a
  • a frame for the corresponding program code is generated based on a definition of the system to be included.
  • the manufacturer of the system to be encapsulated fills the frame with appropriate
  • the TSBI or the VDE will use the binary code to to communicate with the encapsulated system and to automatically generate a web service interface for any type of SOA environment (bus, client, web service interface compliant or not).
  • the TSBI or the VDE allows to generate an SOA interface for a sensor without the need for detailed knowledge about the SOA environment.
  • Connection module establishes the TSBI a direct connection to the systems to be integrated.
  • the VDE or the TSBI does not require any special standard or protocol to interact with the system.
  • the VDE is not an architecture, but a framework that allows to generate an SOA interface for connecting any system into the SOA environment, regardless of which interface the systems have. Since the VDE can also encapsulate heterogeneous systems, the VDE is also referred to as a generic encapsulator Unlike the known NICTA method, the encapsulation of a system in the present invention does not require knowledge of SOA or Web services.
  • the TSBI also provides advanced
  • Connection module are not mentioned. This is, for example, a so-called "Heartbeat" function to ensure that the
  • Encapsulation software and the encapsulated device is still active and available, a so-called “traffic shaping” to protect the network against an unusually large amount of data sent by the sensor, or a so-called.
  • the TSBI does not require a model language for representing the data; it supports any kind of XML representation and encryption.
  • the TSBI is well prepared for deployment in a military environment. All
  • Components are distributed (e.g., each node has its own registry), so malfunctioning a node does not cause the entire sensor network to malfunction.
  • the TSBI provides two
  • Interfaces are available to interact with the encapsulated systems, namely a request / response interface and a publish / subscribe interface.
  • the TSBI preferably does not use
  • Topics topics, identifications. In a military context, all services are distributed.
  • the TSBI does not mix services (service orchestration), service bus, and SOA system encapsulation.
  • the VDE provides static SOA encapsulation for a military-grade system
  • the Lightweight Service Bus Node (LSBN) or another Enterprise Service Bus (ESB) provides the bus infrastructure and may also be drain management capabilities.
  • a service consumer logic on the client side oversees the management of the services also, one
  • the present invention thus relates to the encapsulation of non-service oriented systems to the on
  • connection module includes a generic web service portion that offers outwardly web service compliant interfaces.
  • the interconnect module can also provide non-Web Service compliant interfaces so that current Enterprise Service Buses (ESBs) that are not 100% compliant with standards or have proprietary features can also consume the service.
  • EDBs Enterprise Service Buses
  • the TSBI includes an interface component that must be instantiated depending on the system (the sensor) to be connected and that is connected on the other side to the web service portion (the SOA network),
  • the TSBI provides an interface for generating a SOA interface to the outside and a scaffold for
  • Realization of encapsulation of the sensor includes. This encapsulation can then be implemented outside of the TSBI with the aid of a suitable development environment, that is, "filled with life” depending on the type of sensor to be encapsulated
  • Development environment is the respective manufacturer of the system to be connected (sensor manufacturer)
  • the design of the TSBI is also pure
  • executable software can be programmed so that they can implement encapsulation of a non-SOA-enabled system connected to the computer and the integration of the system into an SOA environment when it runs on the computer or on a microprocessor of the computer.
  • the TSBI infrastructure optimizes the tactical operations while providing significantly reduced radio or network connectivity. This is achieved through particularly advanced data compression methods,
  • the TSBI infrastructure meets the highest
  • the TSBI is a high-performance platform that provides a fast, easy, and cost-effective realization of an SOA infrastructure within existing or existing SOA infrastructure
  • the TSBI is a standard connection module
  • the SOA environment or the way in which SOA processes are handled may be handled by a higher-level organization, such as the North Atlantic Treaty Organization (NATO), the Federal Armed Forces IT Office, the
  • the sensor or its functionality is depicted as a service in the SOA environment.
  • connection module (TSBI) according to the invention is assigned not only to a sensor but to a plurality of sensors. It is also conceivable that a sensor has not just one detector but a plurality of detectors. This makes it possible, for example, for a sensor to detect a spatial area to be monitored by means of a camera, to detect vibrations by means of a geophone and to detect a temperature by means of a thermometer. In such multi-sensor systems, the individual detectors are connected via a sensor node to the first interface of the TSBI. Various sensors can also be connected directly to the connection module.
  • the information and data of various detectors and sensors can be interconnected and be output to the user on a uniform surface.
  • the sensors can only be controlled via the SOA network by one of the users.
  • Figure 1 is a SOA Net zwerk structure
  • FIG. 2 shows a connection module according to the invention in accordance with a first preferred embodiment
  • Figure 3 is a schematic diagram of the combination of a
  • FIG. 4 shows a connection module according to the invention in accordance with a further preferred embodiment
  • FIG. 5 shows the principle of generating an SOA encapsulation of a sensor on the basis of the connection module from FIG. 4;
  • Figure 6 shows the principle of communication between a
  • FIG. 7 shows the principle of a message transmission between a client computer from the SOA environment and an encapsulated sensor on the basis of FIG
  • FIG. 8 shows the principle of using services in an SOA environment over a limited bandwidth network using the connection module of FIG. 4;
  • Figure 9 is a perspective view of an inventive
  • FIG. 10 shows the principle of the encapsulation according to the invention
  • Figure 1 shows a SOA Net zwerk structure, as it can be used for example in the field of security and / or defense technology.
  • the SOA-Net zwerk structure is designated in its entirety by the reference numeral 1.
  • the structure 1 initially comprises a plurality of sensors 2, which are denoted by Sl, S2,... Sn or Sl, S2,... Sm, where n and m are natural numbers> 1.
  • sensors e.g., any weapon systems
  • actuators e.g., any propulsion systems
  • the sensors 2 are, for example, as cameras for detecting a spatial area, geophones for detecting vibrations as Temperature sensors for detecting temperatures, as
  • the sensors 2 are not SOA-capable per se.
  • connection modules 3 are also referred to as the Tactical Service Bus Interface (TSBI).
  • connection module 3 In each case, a plurality of sensors 2 are connected to a connection module 3. However, it is also conceivable that only one sensor 2 to a connection module. 3
  • the TSBIs 3 are preferably arranged in the vicinity of the sensors 2. For example, if the sensors are disposed on an emergency vehicle, a TSBI 3 would preferably also be disposed on the vehicle. The connection of the sensors 2 to the TSBIs 3 takes place
  • first interfaces 3.2 preferably via first interfaces 3.2.
  • Interfaces 3.2 are preferably designed as RS232 and / or LAN interfaces.
  • connection modules 3 are in turn to a
  • the bus structure 4 is, for example, a CAN or a TTCAN bus.
  • the communication infrastructure 4 may be wired or wireless, in particular via radio, be realized.
  • the infrastructure 4 can be embodied as any data transmission connection, for example as a radio connection, from the TSBIs 3 to a switching center via which access to the Internet / to an intranet exists. at In this embodiment, the infrastructure 4 would thus be formed by the data transmission connections and the Internet / Intranet.
  • the connection of the communication infrastructure 4 to the TSBIs 3 preferably takes place via second interfaces 3.4. These are preferably as
  • the SOA-Net zwerk structure 1 has users (so-called user) 5, which are connected to the communication infrastructure 4.
  • the users are labeled Ul, U2, Uo, where o is a natural number> 1.
  • users 5 are connected to the Internet 4 via Internet-capable computers.
  • the computers preferably provide the users 5 with an output device (e.g., a screen, a printer, etc.) for outputting
  • FIG. 2 shows a detail of a TSBI 3 according to the invention, such as, for example, the TSBI1 or the TSBIp. It initially comprises at least one program and / or data memory 6, which may be formed, for example, as a ROM, an EEPROM or a flash memory. In the memory 6 is a
  • Computer program stored which is processed in a computing device 7 TSBI 3.
  • the computing device 7 is
  • the computing device 7 preferably designed as a microprocessor. But it is also conceivable that the computing device 7 as a digital
  • DSP Signal processor
  • Coordinate and control interfaces 3.2 and / or 3.4 The computer program stored in the memory ' 6 is subdivided into at least two sections 8.1 and 8.2, which are stored in different memory areas 6.1 and 6.2 of the memory 6. In the described embodiment, no computer program is stored in a third memory area 6.3; this memory area 6.3 is in this
  • a section 8.1 and / or 8.2 of the computer program can also be stored there.
  • the free memory area 6.3 can also be dispensed with.
  • a first section 8.1 of the computer program comprises those parts of the computer program which relate to standard procedures. This can be, for example, processes that the
  • the first section 8.1 of the computer program is specified by the manufacturer of the TSBI 3 and programmed during or after the production of the TSBI 3 at the end of the tape. Only then is the TSBI 3 delivered to the customers, i. to the manufacturers of the sensors 2, delivered.
  • the sensor manufacturers then develop and program another section 8.2 of the computer program and store it in memory area 6.2 in memory 6.
  • the software programmed by the sensor manufacturer provides a connection between the usually proprietary one
  • the reconnaissance mission can be decentralized by the users 5, i. eg from Germany, coordinated and evaluated.
  • one of the users 5 controls the sensors 2 in a suitable manner. This can take place, for example, via a graphical user interface (so-called graphical user interface, GUI), which is displayed on the screens of the computers assigned to the users 5 and by means of a keyboard, mouse or the like. can be served.
  • GUI graphical user interface
  • the user 5 determines which sensors 2 are actually available in the predefined planum rate. Possibly. can a vehicle, a drone or similar with at least one TSBI 3 and additional sensors 2 in the grid square during the given time period
  • the user 5 Via the SOA network structure 1, the user 5 would then receive information that additional sensors 2 are available for the reconnaissance mission.
  • the user 5 can control the sensors 2 via the associated computer in the desired manner. On the one hand, this includes the activation and deactivation of the sensors 2. On the other hand, however, this also includes a purposeful control of the sensors 2 during their operation, for example, the
  • the activation of the sensor 2 comprises the selection of a sector (a Surveillance area), a control of a scan function (scanning the surveillance area), a track function (tracking an object in the surveillance area) or a pan / tilt head on which the radar sensor is mounted.
  • the control commands of the user 5 for a sensor 2 are first of the fixed predetermined part of the 8.1
  • Sensor manufacturer programmed part 8.2 of the computer program then converts into corresponding control signals for the sensor 2.
  • Each of the sensors 2 can be controlled via the SOA Net zwerk structure 1 only by a user 5. However, the sensed sensor readings provided via the SOA network structure 1 can be detected by multiple users 5. The users 5 can then start immediately with the evaluation of the sensor measured values and thus work out plans for the further course of action in this grid square, for example attack or defense plans.
  • the sensors 2 or their functionality are displayed as services in the SOA environment. This is the capture and
  • FIG. 3 shows a schematic diagram of the present
  • the central components are the notification and the messaging engine, which perform the tasks related to the web service compliant access and with the respective
  • the TSBI must register for the non-service oriented system connected to it.
  • the configuration block does this task.
  • the ' TSBI does not register for the connected SOA
  • the SOA infrastructure can access metadata and service descriptions (WSDL).
  • the TSBI contains a registry in which all known services are stored.
  • the TSBI provides an interface to query these services.
  • the TSBI does not take over the registration for the non-service-oriented system connected to it.
  • the system can query the service lists at the TSBI and their content at least partially into its own
  • the device controller (also called encapsulation software), which must be implemented for the respective non-service-oriented system to be connected, forms the interface between the web service portion and the legacy portion.
  • IDE development environment
  • This IDE can be part of the TSBI.
  • the TSBI does not include a development environment but provides a
  • IDE Interface for generating an SOA interface to the outside and a framework for the realization of an encapsulation of the sensor.
  • This encapsulation can then be implemented outside the TSBI with the aid of a suitable development environment, that is to say, "filled with life” depending on the type of sensor to be encapsulated
  • the IDE is designed so that each manufacturer of a system to be encapsulated from a predetermined framework
  • an Enterprise Service Bus is denoted in Figure 3 and a Lightweight Service Bus is called LSB, WS the Web Services, WSDL a Web Service Definition Language, and XSD an XML Schema File.
  • FIG. 4 shows a further preferred embodiment of the present invention.
  • the division of the connection module 3 into two module units should be emphasized, namely a so-called vendor device encapsulator (VDE) and a so-called lightweight service bus node (LSBN).
  • VDE maps the attached sensor 2 as a service in the SOA network 4.
  • the LSBN prepares the service for transmission over a low-bandwidth radio network ("Radio") as depicted by the first modular unit (VDE) while maintaining the SOA functionality on.
  • the TSBI can either have only the VDE or a combination of VDE and LSBN.
  • the TSBI is a physical device that hosts the two module units.
  • the VDE 10 is preferably implemented as a software system that allows to generate an SOA interface for a sensor 2.
  • Sandbox 11 is a spatially and functionally limited environment
  • Sensor SOA encapsulation refers to the functionality with which the functionality of the sensor 2 in FIG
  • the Sandbox 11 is also used to protect the host system (TSBI) from possible attacks or (software) errors and ensures that the intellectual property of the device manufacturer is protected in the form of the programmed encapsulations. that the user or a malicious person has no way of accessing the software and the
  • Encapsulation Container "12 serves as a container for the sensor encapsulations created with the VDE
  • the Vendor Custom Software "13 is a collection of software and data needed by the sensor encapsulations to communicate with the sensor (s) 2 to be able to interact.
  • Heartbeat 14 refers to heartbeat messages that cause sensor encapsulations to be sent out to ensure that the sensor encapsulations behave correctly.
  • a sensor encapsulation behaves correctly if the sensor 2, the bus 4 and the SOA Web Service behave correctly.
  • Watchdog timer 15 denotes a module which ensures that all sensor encapsulations contained in the sandbox 11 are kept running. The watchdog timer 15 receives from the encapsulations of the sensor 2 Emit heartbeat messages 14 and evaluate them. If a sensor encapsulation during a defined
  • the watchdog timer 15 thus ensures that the service encapsulation is always running and that an error does not affect the entire connection module 3 and possibly puts it out of action.
  • the concept of service heartbeat allows to ensure that processing is from bottom to top (Sensor / Actuator / Effector 2 - Service - Message Bus 16 - Web Service Interface 17, Pub / Sub
  • Interface 18 runs without error.
  • Heartbeat messages must be the ESB 4 and / or the LSBN 22 via the pub / sub module 18's heartbeat service
  • the subscribed service buses (ESB 4 and / or LSBN 22) then receive the heartbeat messages via the module 18 from time to time.
  • BUS 16 is an internal bus system (so-called message bus) that describes the sensor encapsulation with the SOA Web
  • a configuration module 20 (request-response interfaces 17 and publish / subscribe interfaces 18) connects.
  • the sensor 2 encapsulation generator 19 allows the generation of SOA web services and source code projects which, once compiled, yield sensor encapsulations ("Vendor Device SOA Encapsulations").
  • a configuration module 20
  • Configuration Module allows you to configure the host system and the other modules of VDE 10. With service
  • Registry is a module called 21, all sensor
  • the Service Registry 21 provides heterogeneous WSDL files to
  • the WSDL files are customized to the characteristics and functionality of the service bus (e.g., ESB 4 or LSBN 22). With request response
  • Messaging Provider 17 is an interface which indicates the use of the sensor encapsulation Web Services by means of a request-response message exchange pattern
  • modules 17, 18 and 21 practically all the information required about encapsulation is about the SOA environment, particularly about the SOAP, and about the web services
  • Device manufacturer must be provided that realizes the encapsulation of the device 2. This can thus carry out the encapsulation of the device 2 without knowledge and knowledge of the SOA environment, the SOAP and Web Services. The manufacturer only needs to know the interface of the device to be encapsulated and the
  • LLB Light Weight Service Bus
  • the LSB comprises one or more LSB units (LSB Nodes; LSBNs) 22.
  • a request response module 23 provides an interface to the request-response messaging provider 17 of the VDE 10. It transmits incoming request messages to the VDE 10 and receives answer messages that leave the VDE 10.
  • a publish / subscribe module 24 provides a
  • a service discovery module 25 indexes all sensor encapsulation web services present on the VDE 10 and stores the associated service descriptions (e.g., WSDL).
  • the service discovery module 25 makes it possible to query the service descriptions which are located on the LSBN 22 'of other TSBIs 3' (see FIG. Since the TSBI 3 is intended for use in the tactical or military world (e.g., limited bandwidth of the radio networks), this synchronization with other LSBNs 22 does not occur automatically.
  • the synchronization of the TSBI 3 (query the
  • Service Descriptions of Other Nodes LSBN takes place prior to the deployment of the TSBI (e.g., as part of a mission preparation) or during deployment as an exception and upon explicit request of an authorized person.
  • the determined service descriptions are in one
  • This service register 26 is designed to be completely distributed
  • Service register gives.
  • the knowledge of the LSBN 22 about services consists of the totality of service descriptions stored in the service register 26 of each TSBI 3, 3 'of the network.
  • modules such as “Compression” 27, “Encryption” 28, “Traffic Shaping” 29 and “Access Control” 30 will be described in more detail below.
  • These modules are well known in the art, both independently and elsewhere in the SOA environment.
  • the modules known per se are used in a special way and connected to one another in order to realize added value in the SOA environment in comparison to known SOA encapsulations.
  • a compression module 27 compresses all messages leaving the LSBN 22 towards the wireless network and decompresses all messages received by the LSBN 22 from outside the TSBI 3.
  • An encryption module 28 encrypts all
  • a Traffic Shaping module 29 monitors the available bandwidth of the restricted
  • An Access Control Module 30 ensures that the SOA conforms to a lightweight but secure security model, which is appropriate for military networks with less
  • a radio adapter 31 is a module which converts the messages leaving the LSBN unit 22 into data packets
  • the Radio Adapter 31 takes into account special features of the
  • the radio adapter 31 also intercepts data arriving from the radio and converts it into messages that can be understood by the LSBN 22.
  • the TSBI 3 has one
  • the Administration Interface Via the interface 32, the VDE 10 or the LSBN 22 are configured. This is preferably done using an interactively operated
  • the Enterprise Service Bus (ESB) 4 processes Web services that are available on the VDE 10 via the VDE SOA Interface 3.4.
  • the ESB 4 registers Web Services of the VDE 10 by installing WSDL files requested by the Service Registry Module 21 of the VDE 10.
  • a client computer 33 processes Web services available on the VDE 10 via the VDE SOA Interface 3.4.
  • Web service proxies can be generated directly from the WSDL files provided by the service
  • Radio is a radio 34 comprising a transmitter and / or
  • the downstream radio network is designated 35.
  • Connection module 3 from FIG. 5 corresponds to that shown in FIG. In Figure 5 are in addition still some
  • the development computer can be used as a conventional personal computer (PC), as a laptop, a palm computer and possibly.
  • Development computer is represented in Figure 5 by its user 36.
  • the computer is over
  • step 3 (also not shown), a connection is made to the management office of the development computer
  • a namespace for a specific service is subsequently generated via the administration interface 32 in the vendor device encapsulation generator 19. For this, the name of the manufacturer or seller of the sensor 2, a name of the service and a version number must be entered. Then in a step 5 also via the administration interface 32 in the vendor device
  • Encapsulation Generator 19 also defines the service operations. For this purpose functions and notifications are entered. Subsequently, in a step 6, the framework of the program code of the project is likewise downloaded via the administration interface 32 in the vendor device encapsulation generator 19. Then, in a step 7, the user 36 downloads the downloaded project
  • the required software is installed in the sandbox 11 via so-called remote logging (remote desktop).
  • the sensor manufacturer logs on from a remote computer (the development computer 36) to the virtual machine (the sandbox 11). He can load extra software into the Sandbox 11 and install it there.
  • the sensor 2 is released from the development computer and connected to the TSBI 3.
  • the creation of a sensor encapsulation is completed and the functions of the sensor 2 are shown in the SOA environment.
  • connection module 3 of FIG some method steps are indicated by numbers in circles in Figure 6. The method steps are processed in ascending order and essentially at the location where they are drawn
  • a request message in the SOAP (Simple Object Access Protocol) format comes from the client computer 33 via the physical interface 3.4 to the request-response messaging provider 17 of the TSBI 3.
  • the message is in a Step 2 is transmitted via the bus 16 and finally arrives at the Vendor Device SOA Encapsulation Container 12 in a step 3 a step 4, a function is called, which corresponds to the the service addressed by the SOAP message corresponding sensor function by means of reflection (allows
  • the sensor SOA encapsulation 12 interacts with the sensor 2.
  • the output or the response of the sensor 2 is converted in a step 6 into a SOAP message.
  • the response message in SOAP format is transmitted in a step 7 via the bus 16 to the request-response messaging provider 17.
  • the SOAP response message leaves the request-response messaging provider 17 and is sent back to the client 33.
  • a client computer 33 When a client computer 33 wishes to log in to the TSBI 3, it sends a logon message to the publisher /
  • Each notification consists of a topic (subject, subject) and a body (body).
  • the topic is an identification parameter; the body is one
  • connection module 3 from FIG. 7 corresponds to the one shown in FIG FIG. 7
  • a particular event occurs in the sensor 2 (e.g., a radar detects an object and provides a so-called track; a motion sensor reports small changes in acceleration or the like).
  • the sensor 2 e.g., a radar detects an object and provides a so-called track; a motion sensor reports small changes in acceleration or the like.
  • Encapsulation 12 is informed of this in step 2 and invokes the associated notification function.
  • the output or the output of the notification function is converted in a step 3 into an SOA message.
  • the message is transmitted via the bus 16 to the pub / sub messaging provider 18 in a step 4.
  • the SOA message is then in a step 5 to all in the SOA environment at the TSBI 3 as
  • a data connection between the computer 36 and the TSBI 3 is made, for example by connecting the computer 36 to the TSBI 3 by means of a cable.
  • a suitable Web Services Description Language (WSDL) is requested from the service registry 21 of the TSBI 3 and downloaded to the computer 36.
  • the source code for the service proxy is generated from the WSDL.
  • the proxy is imported into the software development tool running on the computer 36 and the Web Service Client is developed.
  • the TSBI 3 is connected by means of a cable to the system which hosts the ESB stub 4 or is connected to the Service Bus Node
  • step 2 is a suitable WSDL (WebMDL).
  • Services Description Language is requested from the Service Registry 21 of the TSBI 3 and installed in the ESB 16 Service Registry.
  • the data transmission via the radio network 35 can take place according to any protocol or standard.
  • the bandwidth of the radio network 35 is well below the bandwidth of civil communication networks (gigabit LAN), for example in the range of only a few bytes / sec or even in the range of only a few kbytes / sec, in particular in the range of about 4 to 20 kBytes / sec and in exceptional cases in a range up to max. 60 kbytes / sec.
  • civil communication networks gigabit LAN
  • Figure 8 shows two TSBIs, namely TSBI A (reference 3) and TSBI B (reference 3 ').
  • TSBI A reference 3
  • TSBI B reference 3
  • the connection modules 3, 3 'from FIG. 8 correspond in each case to that shown in FIG.
  • the LSBN 22 of the TSBI A 3 is, for example, for services a to c while the LSBN 22 'of the other TSBI B 3' is responsible for services d to f.
  • the LSBNs 22, 22 'of the TSBIs 3, 3' of the illustrated network synchronize with each other so that one TSBI can also access and consume the services of the other TSBI.
  • the synchronization does not take place at regular intervals. Rather, the synchronization, in particular for the integration of new TSBIs in the network, either on the express command of a
  • the services respectively administered in the distributed TSBIs 3, 3' are stored in the service discovery modules 25, 25 'of all TSBIs 3, 3', so that each of the LSBNs 22, 22 'contains both the from the VDE 10, 10 'of the own TSBI 3, 3' managed services as well as all of the VDEs 10, 10 'of the other TSBIs 3, 3' of the network knows.
  • information about the services d to f of the TSBI B 3 ' ie also information about the services a to c of the other TSBI A 3 of the network, are stored in the service discovery 25' of the TSBI B 3 '.
  • a client computer 33 of the TSBI A sends a SOAP request message to the request / response messaging provider 17 of the TSBI A.
  • the TSBI A recognizes that the requested service is not located on itself, but on another TSBI B, ie the requested service is not provided by TSBI A but by TSBI B.
  • the TSBI B is known to the network, and in particular the TSBI A, since the TSBI B is listed in the Distributed Service Registry 26 of the LSBN 22.
  • the SOAP message is compressed (unit 27) and encrypted (unit 28) and transmitted to the radio adapter 31 which sends the message to the radio 34 in a step 4
  • a step 5 the message is transmitted from the radio 34 of the TSBI A via the radio network 35 to the radio 34 'of the TSBI B.
  • the message enters the radio adapter 31 'of the TSBI B. Then the message is decrypted and extracted in a step 7 and sent to the
  • Step 10 becomes the appropriate one by reflection
  • the SOAP message is transmitted via the bus 16 'and the request / response messaging provider 17' of the VDE 10 'to the LSBN 22', where the SOAP message is compressed in a step 14, encrypted and sent to the radio adapter 31 '. is transmitted.
  • a step 15 derives the
  • the SOAP message is sent in a step 16 via the radio network 35 to the radio 34 of the TSBI A
  • the SOAP message arrives in the radio adapter 31 of the TSBI A.
  • the received SOAP message is then decompressed and decrypted in a step 18 and sent to the request / response messaging provider 17 of the VDE 10.
  • the SOAP response message exits the request / response messaging provider 17 and is sent back to the client 33.
  • FIG. 9 shows a preferred exemplary embodiment of a TSBI 3 according to the invention. It comprises a housing 40 for receiving the electrical components and components.
  • the housing 40 has upwardly directed an opening which is closed by a cover 41.
  • the lid 41 is releasably, for example.
  • screws 42 mounted on the housing 40.
  • the housing 40 and the cover 41 are preferably made of metal, in particular die-cast aluminum. At the front of the housing 40 are various
  • Plug elements formed.
  • a first Ethernet port 43, a second Ethernet port 44, two USB ports 45, an RS232 port 46, an audio and / or video port 47, a port 48 for VGA and a CAN bus, as well a power supply terminal 49 is provided.
  • the reference numeral 50 denotes an on / off switch.
  • conventional connector elements for the appropriate format, for example a conventional Ethernet connector for the connectors 43 and 44, two conventional USB connectors for the connectors 45, an RS232 connector for the RS232 connector 46, audio and video jacks for the
  • Port 47 and a VGA connector and a CAN bus connector for port 48. While capping a new sensor 2 or managing the TSBI 3 can connect to port 43 or 44
  • the power supply is connected to terminal 49.
  • the TSBI 3 is a so-called convergence module which can convert any firmware of the sensors 2 into an SOA-compatible standard.
  • the TSBI 3 includes both hardware and software components.
  • the goal of the TSBI 3 is to provide simple and complex functionalities as services according to WebService standards. The main requirement for the
  • the VDE 10 is able to integrate legacy systems that do not offer a WebService interface by themselves into a modern service-oriented architecture.
  • This encapsulation can be carried out by the manufacturer (vendor) of the device 2 to be encapsulated itself.
  • the automatisms and tools of the VDE 10 support the manufacturer.
  • the VDE infrastructure 10 adapts the SOA mechanisms to existing programming languages such that the manufacturer does not need knowledge about web service interfaces (WSDL) for the encapsulation.
  • WSDL web service interfaces
  • the manufacturer does not need knowledge about web service interfaces.
  • the VDE 10 generates the appropriate WSDL for Bus 4 / Client 33 and the appropriate interface for device 2.
  • the manufacturer also gets a C ++ template in which he gets his
  • the sensor manufacturer (vendor) does not have to disclose its interface, which can significantly improve manufacturers' acceptance of the invention.
  • reflections with C ++ make it possible, for example, to query information about classes or their instances in object-oriented programming, such as their visibility, the data type of the return value or the type of the transfer parameters Query options are language-specific: in C ++, the corresponding memory address must be found at runtime at the right time for the function to be called. Readable C ++ code is written after the
  • the VDE 10 has a repository in which all service descriptions are stored.
  • Each VDE 10 brings its own repository. So, there's no central "Achilles Heel" node that holds the data and could fail, and the distributed, distributed architecture makes a TSBI network difficult to maintain
  • a first TSBI A can access the functionality of a second TSBI B via a radio network 35 (see Figure 8).
  • the devices 2, which are encapsulated by the VDE, must be used for
  • Web service calls are typically simultaneous, i. in large numbers.
  • a device processes calls but sequentially. This would make a renewed call while processing an already
  • the VDE 10 solves this problem by buffering the service calls incoming via the request / response module 17 at least until they can be processed. Module 17 also handles the processing of incoming calls in the correct order. When calling the incoming service
  • the module 17 can this
  • Errors that arise in the VDE 10 are output as "SOAP errors” (error messages) from the VDE 10. This applies in particular to the software components that are imported by the manufacturers into the VDE 10. In this way it is ensured that a This means that faults of the encapsulated device 2 appear as SOAP faults and can be detected ..
  • the sandbox 11 completely isolates the devices 2 in the VDE 10. This increases the safety and security at the same time the availability, because the isolated devices are difficult to attack 2. Furthermore, it is ensured by means of the watchdog timer 15 that the devices 2 as well as the sandbox 11 itself are available, for which the encapsulation of a device 2 transmits one, preferably regularly, one at predetermined times Heartbeat message to the watchdog 15. In the event of a system crash, the sandbox 11 will become automatic restarted. A "freeze" of the system is thus
  • the adaptive service bus interface provides
  • connection module 3 The services generated by the connection module 3 and corresponding to one or more functions of the encapsulated device 2 can be addressed by any other nodes (so-called nodes) of the SOA network.
  • nodes nodes
  • Connection module 3 takes place only via the web service interface 17 (request / response) and via the pub / sub-interface 18 (Subscribe / Publish).
  • service firmware is transferred from one node to another node so that they can communicate with each other.
  • connection module 3 does not rule out that in the case of the connection module 3 according to the invention, an export file generated by the VDE 10 can be transmitted to other connection modules 3 or other VDEs 10 in order to encapsulate the same devices 2 there. It is thus possible to transfer the encapsulation created for a device 2 to other VDEs 10 so that devices of the same type of the device 2 can be encapsulated there with minimal effort.
  • the firmware of the TSBI 3 does not automatically transmit the service to the network. Rather, the service descriptions must be installed in the ESB 4 Service Registry. The ESB 4 knows that one particular
  • Service is available by receiving the heartbeat notifications of the service.
  • the service itself is - unlike, for example, in the US 2007/0236346 AI - never transferred between the nodes, but it is consumed remotely by means of SOAP.
  • TSBI 3 If the TSBI 3 is used in a military environment, it can use the LSBN 22. Unlike in US 2007/0236346 AI, there is no central platform or
  • the LSB is a fully distributed military service bus that synchronizes with the other nodes. Neither drivers nor services are transferred from one TSBI 3 to another TSBI 3 'over the LSB.
  • the LSBN 22 only installs service
  • Illustrations for example in the WSDL, on request and services are provided via remote procedure calls
  • FIG. 10 shows a TSBI 3, a non-SOA-capable device 2 to be encapsulated per se, and a client 36 that wishes to access the device 2 from the SOA environment.
  • the device 2 is, for example, a movable camera or a movable weapon system.
  • a first function Fktl of the device 2 corresponds, for example, to a swiveling and a second function Fkt2 to a tilting of the camera or of the weapon.
  • Fkt3 A function for confirming the successful Schwenk designated. Be tilting movement.
  • For a weapon could be the third Function Fkt3, for example, be a function for firing the weapon.
  • the device 2 may also have more or less or other than the illustrated three functions Fktl to Fkt3. These functions may be invoked by at least one physical interface 60 and may be delivered via an API (Application Programming
  • Reference numeral 61 denotes.
  • the program code 61 is typically proprietary, often programmed in the C ++ programming language and known only to the device manufacturer 2.
  • the device 2 is driven via the interface 60 with commands, for example from a computer or a joystick.
  • calls possibly with specific transfer parameters, are sent to the interface 60 of the function Fktl to Fkt3 to be executed.
  • a call could be called "panning 45 °", in which case the first function Fktl is called and 45 ° one
  • the function Fktl can, for example, a result
  • Function Fkt3 is provided in order to successfully pivot and / or tilt the device 2 to announce.
  • Function Fkt3 is called after function Fktl, eg without a transfer parameter.
  • function Fkt3 may return a Boolean value ("1" or "0") to
  • the TSBI 3 comprises a frame structure 62, which is automatically generated on the basis of specifications of the manufacturer of the device 2.
  • the manufacturer indicates, for example, which function (s) of the functions Fktl to Fkt3 of the device 2 he wants to encapsulate and if and if so which parameters (input variables,
  • Output variables expect or return the functions to be encapsulated.
  • the manufacturer of the device 2 specifies the function "panning", as input parameter an angle variable (eg of the type integer) for a movement of the device 2 and as output parameter a yes / No statement (eg of the Boolean type) as information about whether the panning was successful, ie whether the desired end point has been reached.
  • the manufacturer can specify the appropriate parameters for the function Fct2 "Tilt".
  • the manufacturer can specify for a camera, for example as the function to be encapsulated "check movement", no input parameters and as output parameter a yes / no statement (for example of the Boolean type), if the pan / tilt was successful.
  • the administration interface 32 (see Figures 4 to 8) of the TSBI 3 is used to define the framework or the frame structure 62. Generated is the
  • the frame structure 62 then by the Vendor Device Encapsulation Generator 19 in VDE 10.
  • the frame structure 62 also includes inputs defined by the manufacturer 63 and outputs 64 for the input and output parameters of the encapsulated Functions Fctl to Fkt3.
  • the inputs 63 and outputs 64 can, for example, by a so-called.
  • Admin GUI Graphical User
  • the program code 61 of the corresponding function in the frame structure 62 must be stored or integrated in a predetermined position of the frame structure 62.
  • the program code 61 '(cl,...) Of the second function Fkt2 of the device 2 is stored in the frame structure 62.
  • Frame structure 62 stored program code 61 corresponds to the vendor-custom software block 13 in the sandbox 11 of the TSBI of Figures 4 to 8.
  • the manufacturer of the device 2 can also simply store or program references to the program code 61 in the device 2 in the frame structure 62 at the predetermined location of the frame structure 62.
  • the reference includes, for example, a call 65 and a program code for receiving a result 66.
  • Such a call 65 is shown by way of example for the encapsulation of the first function Fkt1 in the frame structure 62 in FIG.
  • the program code for receiving a result 66 is programmed for the first function Fktl.
  • the call of the program code 61 of the first function Fkt1 of the device 2 is illustrated by a solid line arrow from the TSBI 3 to the interface 60 of the first function Fkt1 of the device 2.
  • the return of the result of the function Fktl by a solid line
  • the desired target of the swivel movement eg a Boolean value
  • the invocation of the third function Fkt3 is illustrated in FIG. 10 by a dashed line arrow from the TSBI 3 to the API 60 of the third function Fkt3 of the device 2. Likewise, the return of the result of the function Fkt3 is indicated by a dashed line
  • the TSBI 3 not only functions Fktl to Fkt3 of the device 2, but also other functions that run, for example, only on a separate computer 67 arranged outside the device, in particular a computer, by the TSBI 3 in an SOA environment. It is conceivable that
  • Frame structure 62 is copied or programmed there (Vendor Custom Software 13) or only references to the
  • the computer 67 is connected to the device 2 via a data transmission connection (not shown) so that a processing of the program code on the computer 67 triggers a corresponding action or function of the device 2 or processes return values from the device 2 can. In this way it is also possible, not just individual functions of the device 2 or external computer 67, but also complex systems for
  • a client 36 from the SOA environment by means of SOA calls access the encapsulated functions Fktl to Fkt3 or feedback of the functions (eg response) in the SOA Receive and process the environment.
  • a request 68 of the client 36 is shown to the encapsulated first function Fktl.
  • the request 68 may comprise one or more transfer parameters, in the case of the "swivel" function, for example, an angle specification for the swivel movement
  • the response 69 may also include one or more return parameters, in the case of the "pan" function, for example, information as to whether the pan movement was successful
  • the TSBI 3 "translates" the SOA call into a format that is understandable or compatible for the device 2 or the program code stored there, this being done by the algorithms specified by the manufacturer of the TSBI 3.
  • the manufacturer of the TSBI 3 The manufacturer of the
  • the processing of several SOA calls 68 in the TSBI 3 or in the device 2 is coordinated by the TSBI 3.
  • the SOA calls 68 possibly assigned priorities of the calls 68 can be translated into the proprietary device-specific environment and taken into account there. The consideration of priorities is important, since otherwise, using the example of a trained as a camera device 2, the third function Fkt3 provides a false result with respect to the success of the pan or tilt movement, if not First, the first or the second function Fktl or Fkt2 is completely processed.
  • the third function would lead to a triggering of the weapon, although the final position of the pan or tilt movement has not been reached.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Die Erfindung betrifft ein Verbindungsmodul (3) zum Anbinden mindestens eines Sensors (2), Effektors oder Aktuators an ein Service Oriented Architecture-, genannt SOA-, Netzwerk (4), wobei eine Funktionalität des mindestens einen Sensors (2) als ein Dienst im SOA-Netzwerk (4) abgebildet ist. Um an sich nicht-SOA-fähige Sensoren (2) in ein SOA-Umfeld einbinden zukönnen, wird vorgeschlagen, dass das Verbindungsmodul (3) mindestens eine erste Schnittstelle (3.2) zum Anschluss des mindestens einen Sensors (2), Effektors oder Aktuators und mindestens eine zweite Schnittstelle (3.4) zum Anschluss des SOA-Netzwerks (4) sowie ein Rechengerät (7) zum Abarbeiten eines Computerprogramms aufweist, wobei ein Teil (8.1) des abzuarbeitenden Computerprogramms standardmäßig vorgegeben ist und ein anderer Teil (8.2) des Computerprogramms von einem Hersteller des mindestens einen Sensors (2) frei programmierbar ist, um eine Anpassung einer auf dem mindestens einen Sensor (2) vorhanden Firmware an das SOA-Umfeld zu realisieren. Die Erfindung betrifft auch eine Moduleinheit (22) des Verbindungsmoduls (3), welche den im SOA-Umfeld abgebildeten Service für eine Übertragung über ein militärisches Funknetz (35) mit niedriger Bandbreite unter Beibehaltung der SOA-Funktionalität aufbereitet.

Description

Titel: Verbindungsmodul zum Anbinden mindestens eines Sensors, Aktors oder Effektors an ein Service
Oriented Architecture- (SOA-) Netzwerk
Beschreibung
Die vorliegende Erfindung geht aus von einem Service Oriented Architecture- (S0A-) Netzwerk. SOA erweitert das Konzept von Web-Services zu einer Architektur für umfassende und Service basierende Anwendungen, wobei existierende Systeme und
Anwendungen einbezogen unter Einsatz neuer Funktionalitäten beschleunigt werden. Aus dem Stand der Technik ist SOA für die unterschiedlichsten Anwendungen bekannt. SOA ist eine Informationstechnologie ( IT) -Architektur mit flexiblen
Software-Einheiten (sogenannten Services) als zentralem
Konzept. Bei Verwendung des SOA-Konzepts für
Geschäftsanwendungen realisieren oder unterstützen Services Geschäftsfunktionen und sind an diesen ausgerichtet. Sie sind unabhängig und lose gekoppelt und in der Regel räumlich verteilt (vgl. bspw. US 2009/0281861 AI). Auch im Bereich der Telemedizin ist das SOA-Konzept bekannt (vgl. bspw. US
2009/0254362 AI) .
Schließlich wird das SOA-Konzept auch in zunehmendem Maße im Bereich der Sicherheits- und Verteidigungstechnik eingesetzt (vgl. EP 2 112 624 AI). In diesem Fall können in ein SOA- Netzwerk integrierte Sensoren beispielsweise als Kameras zum Erfassen eines definierten räumlichen Bereichs, als Geophone zum Detektieren von Erschütterungen oder als beliebig andere Sensoren ausgebildet sein, welche Informationen über ein zu überwachendes räumliches Gebiet, ein zu überwachendes
Einsatzfahrzeug oder ähnliches liefern. In ein SOA-Netzwerk integrierte Effektoren können als beliebige Waffensysteme, bspw. Kanonen auf einem Panzer, aber auch als Störsender, Nebelwerfer oder ähnliches ausgebildet sein. In ein SOA- Netzwerk integrierte Aktuatoren können als beliebige Elemente ausgebildet sein, welche eine Eingangsgröße in eine
andersartige Ausgangsgröße umwandeln, um eine gewünschte
Aktion oder einen Effekt hervorzurufen. Insbesondere kann ein Aktuator als ein Elektromotor, ein Elektromagnet oder ein beliebiges Antriebssystem ausgebildet sein. Um die Sensoren, Effektoren oder Aktuatoren an das SOA-Netzwerk anschließen und in das SOA-Konzept integrieren zu können, müssen diese SOA-fähig sein. In den nachfolgenden Ausführungen wird der Einfachheit halber nur auf Sensoren Bezug genommen. Die
Ausführungen gelten in entsprechender Weise jedoch auch für Effektoren, Aktuatoren und beliebig andere Teilnehmer eines SOA-Netzwerks .
Nachfolgend wird näher auf das Prinzip der sogenannten vernetzten Operationsführung (Operationelles Framework) eingegangen. Das Aufgabenspektrum und das sich daraus
ableitende Fähigkeitsprofil der Sicherheitsorgane,
insbesondere nationaler Streitkräfte, wie bspw. der
Bundeswehr in Deutschland, oder multinationaler Streitkräfte (z.B. der NATO), werden durch die sicherheits- und
verteidigungspolitischen Vorgaben sowie die internationalen Verpflichtungen der jeweiligen Nation oder des
multinationalen Zusammenschlusses bestimmt. Um in dem
vorgegebenen Aufgabenspektrum eine nachhaltige Verbesserung der Einsatzfähigkeit unter konsequenter Konzentration auf die Kernfähigkeiten zu erreichen, wird in zunehmendem Maße ein Transformationsprozess eingeleitet, durch den im Hinblick auf die teilstreit kräfteübergreifenden und multinationalen
Einsätze und die daraus resultierenden
Interoperabilitätsforderungen Visionen und Denkansätze unter der Überschrift der vernetzten Operationsführung (NetOpFü) immer stärker in den Fokus der konzeptionellen Diskussionen rücken . Konkret bedeutet NetOpFü, dass ein umfassender
Informationsverbund „Führung, Aufklärung, Wirkung
einschließlich Einsatzunterstützung" zu schaffen ist, der sich vertikal über alle Führungsebenen und horizontal über alle funktionalen Aufgabengebiete erstreckt, um alle
Beteiligten angefangen vom einzelnen Soldaten, über die militärischen Führungsebenen, die Unterstützungsinstanzen bis hin zu den politischen Entscheidungsebenen mit den jeweils wichtigen Informationen zu versorgen. Da die Streitkräfte aus einer Vielzahl von Elementen bestehen, die in einer
gemeinsamen Operation zur Wirkung gebracht werden sollen, können Synergieeffekte nur dann entstehen, wenn die
beteiligten Elemente bzw. Einheiten nicht als Individuum sondern als Teil eines Ganzen agieren.
Die Verbesserung der Informationsqualität und des
Informationsaustausches bedingt durch die Fähigkeit,
Informationen ganzheitlich zu erfassen, auszuwerten, zu verdichten, bereit zu stellen und zu sichern, bildet die Grundlage für einen effektiven und effizienten
Führungsprozess .
Grundlegende Voraussetzung für diesen wirkungsvollen
Informationsverbund und die damit verbundene Dominanz im Informationsraum ist die konsequente Anwendung der modernen Informationstechnik. Jedoch noch zwingender sind die
Netzwerkfähigkeit der einzelnen Elemente sowie die
Interoperabilität untereinander aber auch mit den
Informationssystemen anderer Teilstreitkräfte (z.B. Heer, Luftwaffe, Marine), mit den Systemen der Partnernationen und den zivilen und militärischen Dienststellen. Durch eine medienbruchfreie Kommunikationsinfrastruktur die den
übergeordneten Informationsdiensten adäquate Transportdienste unterschiedlichster Ausprägungen und Qualitäten zur Verfügung stellt, wird ein echt zeitnaher Informationsaustausch
sichergestellt, der die bisher weitgehend getrennten und unterschiedlich strukturierten Informationen in einem
Informationsverbund zusammenführt .
Nachfolgend wird näher auf das Prinzip der Service
orientierten Architektur ( architekturelles Framework)
eingegangen. Interoperabilität ist der Schlüssel zu
Streitkräftegemeinsamkeit, Multinationalität und
Flexibilität. Sie ist umfassende Klammer um alle
Fähigkeitskategorien. Innerhalb der NATO wie auch national ist die Verwendung der Methode „Architektur" vorgegeben, die sicherstellen soll, dass die Interoperabilitätserfordernisse bezüglich Technik, Verfahren und Methodik erfüllt werden können. Ein Vorteil des Service orientierten
Architekturprinzips (SOA) liegt in der Möglichkeit, einmal als sogenannte Dienste oder Services implementierte
Funktionalitäten mit geringem Aufwand wiederzuverwenden und anderen Systemen zur Nutzung bereitzustellen. Eine Serviceorientierte Architektur ist eine, wie der Name schon sagt, dienstbasierte Architektur einer Softwarelandschaft,
idealerweise realisiert mit Web Services.
Das SOA-Prinzip wird nachfolgend am Beispiel der
Implementierung in Geschäftsprozessen näher erläutert. Statt einem bestimmten Teilprozess eine fixe, monolithische IT
( Informationstechnologie ) -Lösung zuzuweisen, arbeitet SOA mit kleineren Einheiten. Die einzelnen, wieder verwendbaren
Business Services werden lose gekoppelt und je nach
Geschäftsprozess konfiguriert. Man stelle sich dies wie einen normalen Kauf-Vorgang vor: Ein bestimmter Geschäftsprozess
(Service-Konsument) bezieht aus einem Pool von Einzel- Services (Service-Anbieter) die von ihm benötigte Kombination und erhält so eine quasi maßgeschneiderte IT-Unterstützung. Voraussetzung ist eine genaue Definition der einzelnen
Business Services (Service-Vertrag) . Der große Vorteil des SOA-Konzepts ist, dass bei Änderungen im Geschäftsprozess nicht sofort in eine neue IT-Lösung investiert, sondern nur die Kombination der Services
angepasst werden muss. Dies macht Unternehmen insgesamt wendiger und flexibler und verschafft ihnen so einen
Vorsprung gegenüber den Wettbewerbern. Genau darauf legen Anwender Wert, dass sie dank dem flexiblen Handling von Geschäftsprozessen schnell auf saisonale Bedingungen wie Spitzennachfrage oder veränderte Kundenanforderungen
reagieren und dank einer zukunftsorientierten Architektur auch langfristig ihr Wachstum unterstützen können.
Ganzheitlich betrachtet stehen Flexibilität und
Wiederverwendbarkeit sowie die Möglichkeit der
Orchestrierung, d.h. der flexiblen Kombination der Services im Vordergrund.
Jedoch muss eingeräumt werden, dass die technologische
Umsetzung diesbezüglich derzeit noch in ihren Anfängen steckt. Die Hauptsache jedoch ist, dass die Geschäftsziele und IT-Strategie eines Unternehmens durch SOA näher
zusammenrücken. SOA verhilft Anwendern zu einer ständigen Optimierung ihrer Geschäftsprozesse, zu Innovation und höherer Effizienz. Um dies jedoch wirklich zu erreichen, müssen die betreffenden Prozesse unbedingt genau definiert und die Wiederverwendbarkeit der Services sichergestellt werden .
Nachfolgend wird näher auf das Prinzip der vernetzten
Operationsführung (NetOpFü) in Kombination mit SOA
eingegangen. In der zivilen Geschäftswelt sind
serviceorientierte Architekturen (SOA) als Infrastruktur für Geschäftsprozesse und deren Management für den
wirtschaftlichen Erfolg und die Wettbewerbsfähigkeit der Unternehmen ausschlaggebend. Der Fokus serviceorientierter Architekturen liegt auf der Prozess-Standardisierung , - Automatisierung und -Verbesserung einerseits und der Flexibilität bedingt durch die Dynamik der Märkte und der Kundenanforderungen andererseits .
Ausgehend von der gedachten Synonymität der Begriffe
„Wettbewerbsfähigkeit" und „Wirkungsüberlegenheit" und der Analogie der Prozessfaktoren sowie der Flexibilität bedingt durch die Dynamik der Einsätze folgt, dass eine
serviceorientierte Architektur (SOA) als Infrastruktur für die missionsbezogenen militärischen Prozesse und Szenarien und deren Management für die Wirkungsüberlegenheit und den Erfolg des Einsatzes ausschlaggebend sein kann. Bei dieser Parallelisierung der zivilen und der militärischen Welt muss jedoch ein ganz entscheidender Aspekt betrachtet werden. Die organisatorischen und strukturellen Einteilungen in
stationäre, verlegbare und mobile Bereiche sind in der zivilen Geschäftswelt bei Weitem nicht so ausgeprägt wie in den militärischen Einsatzszenarien und müssen daher bei der Konzeption berücksichtigt werden.
Bei der konzeptionellen und gedanklichen Fortsetzung der SOA- Konzeption ist aber zu berücksichtigen, dass die
technologische Parallelität bisher im Wesentlichen nur zwischen der zivilen Welt und dem stationären Bereich gegeben ist .
Bezogen auf die Informationsübertragung sind leistungsfähige und vor allem interoperable Kommunikationssysteme für den angestrebten Informationsverbund von entscheidender
Bedeutung. Während sich die Informationsübertragung der
Großverbände auf ein leistungsfähiges Weitverkehrsnetz abstützen muss, das mitunter wegen der Weiträumigkeit des Operationsgebietes bis auf die Bataillonsebene reichen kann, müssen die lokalen Subsysteme der mobilen Teilnehmer und Fahrzeuge der unteren Hierarchieebenen über mobile
Funksysteme in den Informationsverbund einbezogen werden, wobei diese Funksysteme in der Regel im Vergleich zu den Weitverkehrsnetzen nur eine beschränkte Bandbreite zur
Verfügung stellen können. Dieser Aspekt wird in den
Architekturbetrachtungen durch das Domänenkonzept abgedeckt, das die Homogenität des gesamten Informationsverbundes abdeckt aber gleichzeitig auch den autarken Betrieb einzelner Domänen ermöglicht
Interoperabilitätsforderungen existieren aber nicht nur im Bereich der Informationsübertragung. Gerade durch die
geforderte Unterstützung kleinerer multinationaler
Eingreifkräfte entstehen Interoperabilitätsforderungen hinsichtlich Informationen-Sharing (Nutzung der Informationen durch mehrere Teilnehmer) und Sicherheit.
Diese ehrgeizigen operationellen Zielvorstellungen sind nur durch flexible, adaptive und hochgradig vernetzte
Informations- und Kommunikationsinfrastrukturen erreichbar, wie sie durch konsequente Verwendung der Service orientierten Paradigmen zur Verfügung gestellt werden können.
Verschiedene bekannte Aktivitäten haben über die gesamte Spanne militärischer Einsätze das Potenzial aufzeigen können, das in der Anwendung einer serviceorientierten Architektur (SOA) steckt, die die technischen und fachlichen Dienste und Funktionalitäten in Form von lose gekoppelten Services vorsieht .
In den vorangegangenen Abschnitten ist bereits angedeutet worden, dass die Basis für eine mögliche Realisierung eines SOA-basierten Einsatz unterstützenden Systems heute bereits verfügbare Lösungen aus dem zivilen Bereich sein könnten. Die aus heutiger Sicht unproblematische Integration dieser
Lösungen bietet eine homogene infrastrukturelle Basis für die Umsetzung der erarbeiteten Konzeption. Eine kritische
Komponente ist in diesem Umfeld der taktische Bereich mit seinen verlegbaren und mobilen Anteilen, der jedoch insbesondere für die oben angedeuteten Einsatzszenarien eine maßgebliche Rolle spielt, um die Wechselwirkungen zwischen einer serviceorientierten Architektur und dem taktischen Prozess aufzuzeigen und den operationellen Nutzen einer SOA in Bezug auf ein optimales Verhalten im Rahmen der
Auftragstaktik zu demonstrieren.
Die Entwicklungsstrategie von NetOpFü und NNEC (NATO Network Enabled Capabilities ) basiert darauf, dass die notwendigen operationellen Fähigkeiten sich durch die Symbiose von unabhängigen Systemfähigkeiten ergeben.
Einzelsystemfähigkeiten, die in sukzessiven
Entwicklungszyklen entstanden sind, müssen modular aufgebaut sein/werden, damit eine Zusammenführung zur Bildung der
NetOpFü-Gesamtsystemfähigkeit problemlos bewerkstelligt werden kann. Die konsequente Verwendung eines
serviceorientierten Ansatzes unterstützt die evolutionäre Entwicklung von NetOpFü, indem dieser Ansatz die Bündelung der Fähigkeiten forciert und somit ein solides Konzept für die NetOpFü-Entwicklung darstellt.
Ein ganz wesentlicher Aspekt, der in dieser ganzheitlichen Betrachtung nicht in den Hintergrund geraten darf, ist die Einbindung der Einzelsystemfähigkeiten, die durch bestehende Altsysteme (im weiteren Verlauf als Legacy-Systeme
bezeichnet) erbracht werden. Die Befähigung zur vernetzten Operationsführung auf der Basis des Service orientierten Paradigmas setzt voraus, dass die Systemfähigkeiten als (Web- ) Services verfügbar sind und konsequenterweise auch über Web- Service konforme Schnittstellen auf dieses zugegriffen werden kann. Diese Eigenschaft ist bei Legacy-Systemen prinzipiell nicht gegeben. Da zurzeit aber bei der Bundeswehr eine breit gefächerte Vielfalt an Legacy-Systemen unterschiedlichster Hersteller in der operationellen Nutzung ist, kann die SOA- Einführung nur dann Ziel führend sein, wenn auch diese
Legacy-Systeme flächendeckend integriert werden. Darüber hinaus haben die Infrastruktur-Komponenten noch nicht den Reifegrad erreicht, der für einen Verwendung in einer (hoch- ) mobilen Einsatzumgebung erforderlich ist. Hier liegt der Fokus insbesondere auf den Funktionalitäten für die
Optimierung der Algorithmen in Einsatzszenarien im taktischmobilen und verlegefähigen Bereich mit eingeschränkten und instabilen Netzwerkbedingungen. Für den mobilen Bereich grundlegende Mechanismen, um wichtigen militärischen
Ansprüchen - wie beispielsweise Mobilität oder die
Unterstützung eines lokalen Kollaborationsprozesses zwischen Plattformen zur koordinierten Wirkung - zu genügen, müssen in die Infrastrükturkomponenten integriert werden.
Um den vollen Funktionsumfang einer Service orientierten NetOpFü-Befähigung zu erreichen, müssen die Systemfähigkeiten bestehender, nicht serviceorientierter Systeme
herstellerunabhängig so gekapselt werden, dass von außen durch andere Systeme ein Zugriff über Webservice konforme Schnittstellen möglich ist. Zur Nutzung dieser als Service verfügbar gemachten Systemfähigkeiten auch in einem (hoch-) mobilen bzw. aus einem (hoch- ) mobilen Segment heraus muss auch die Infrastruktur auf die besonderen Charakteristiken ausgelegt sein.
In der IEEE-Veröffentlichung „Service-Oriented Sensor Data Interoperability for IEEE 1451 Smart Transducers" von Song, Eugene Y., veröffentlicht im Mai 2009, ist eine Möglichkeit dargestellt, herkömmliche nicht SOA-fähige Sensoren bzw.
Aktuatoren mittels eines geeigneten Verbindungsmoduls in eine SOA-Umgebung zu integrieren. Voraussetzung ist allerdings, dass die Sensoren bzw. Aktuatoren einem MikroController und einer Netzwerkschnittstelle (einem Transducer) zugeordnet sind. In der Veröffentlichung wird eine Kapselung eines Sensors bzw. Aktuators in zwei Schichten beschrieben. In einer unteren Schicht bildet ein Transducer eine IEEE 1451.x- Schnittstelle. In einer oberen Schicht, wird ein IEEE 1451.x Kommunikationsmodul, das in der Lage ist, mit dem Transducer zu kommunizieren, in einen SOA Web Service integriert.
Aus der IEEE-Veröffentlichung „Open Sensor Web Architecture : Core Services" von Chu, Xingchen; Kobialka, Tom; Durnota, Bohdan; und Buyya, Rajkumar aus dem Jahr 2006, ist eine sog. NICTA Open Source Web Architecture (NOSA) beschrieben, durch die herkömmliche nicht SOA-fähige Sensoren bzw. Aktuatoren mittels eines geeigneten Verbindungsmoduls in eine SOA- Umgebung integriert werden können. Bei NOSA wird jedoch keine direkte Verbindung zu dem Verbindungsmodul hergestellt. NOSA baut auf dem Sensor Web Enablement (SWE) Standard auf, der von dem Open Geospatial Consortium (OGC) definiert wurde. SWE ist ein Standard, der ein Anforderungsprofil bzw.
Spezifikationen für Schnittstellen, Protokolle und
Verschlüsselungen umfasst, die das Erkennen, den Zugriff und den Erhalt von Sensor- bzw. Aktuatordaten sowie Sensor- Verarbeitungs-Services ermöglichen.
Beiden bekannten Verfahren zum Anbinden von nicht-SOA-fähigen Systemen in ein SOA-Umfeld ist gemein, dass sie ganz konkrete Anforderungen an das einzubindende System stellen, also nicht flexibel beliebige Sensoren bzw. Aktuatoren in das SOA-Umfeld einbinden können.
Aus der US 2007/0236346 AI ist ein Verfahren zum Anbinden mindestens eines nicht servicefähigen Geräts (z.B. Sensors, Effektors oder Aktuators) an ein Service Orientiertes
Netzwerk (OSGI (Open Services Gateway Initiative) - Architektur) beschrieben. Dabei wird für jeden Gerätetyp beim Gerätehersteller individuell eine entsprechende Kapselung programmiert, um das Gerät in der Service orientierten
Umgebung abzubilden. Das erfordert beim Gerätehersteller Wissen über die Service orientierte Umgebung, das in der Regel nicht vorhanden ist und teuer zugekauft werden muss . Außerdem ist die individuelle Kapselung der Geräte sehr aufwendig in Erstellung und Wartung der Kapselung. Des weiteren ist die Flexibilität der individuellen Kapselung sehr beschränkt. Eine Änderung des verwendeten Service Busses (z.B. ESB (Enterprise Service Bus) vom Typ Websphere oder vom Typ SOPERA der aktuellen Version 3.3 oder einer neueren oder Nachfolge-Version (SOPERA „Swordfish") ) macht sofort eine Neu-Erstellung oder zumindest aufwendige Umprogrammierung der Kapselung erforderlich. Entsprechendes gilt auch bei Änderung des gekapselten bzw. zu kapselnden Geräts. Schließlich kann es bei dem bekannten Verfahren dazu kommen, dass es zu
Inkompatibilitäten kommen kann, wenn von verschiedenen
Herstellern stammende Geräte, deren Kapselung durch die verschiedenen Hersteller realisiert wurde, zu einem Service orientierten Netzwerk verbunden werden. Der Grund dafür ist, dass es sich bspw. bei einer SOA nicht um einen verbindlichen Standard, sondern lediglich um eine Empfehlung handelt. Das kann dazu führen, dass von verschiedenen Herstellern
realisierte Kapselungen zwar alle SOA-konform sind, aber untereinander gar nicht oder nur eingeschränkt kompatibel sind .
Ausgehend von dem beschriebenen Stand der Technik liegt der vorliegenden Erfindung deshalb die Aufgabe zugrunde, eine Möglichkeit zu schaffen, wie ursprünglich nicht SOA-fähige Sensoren auf eine möglichst einfache und kostengünstige Weise in eine SOA-Netzwerk-Struktur integriert werden können.
Zur Lösung dieser Aufgabe schlägt die vorliegende Erfindung den Einsatz eines Verbindungsmoduls zum Anbinden mindestens eines Geräts an ein Service Oriented Architecture- (SOA-) Netzwerk vor, wobei eine Funktionalität des mindestens einen Geräts als ein Dienst im SOA-Netzwerk abgebildet ist. Das Verbindungsmodul weist mindestens eine erste Schnittstelle zum Anschluss des mindestens einen Geräts und mindestens eine zweite Schnittstelle zum Anschluss des SOA-Netzwerks auf. Außerdem weist das Verbindungsmodul ein Rechengerät zum
Abarbeiten eines Computerprogramms auf, wobei ein Teil des abzuarbeitenden Computerprogramms vorgegeben ist und ein anderer Teil des Computerprogramms von einem Hersteller des mindestens einen Geräts frei programmierbar ist, um eine Anpassung einer auf dem mindestens einen Gerät vorhanden Firmware an das SOA-Netzwerk zu realisieren.
Der vorgegebene Teil des Computerprogramms wird vorzugsweise vom Hersteller des Verbindungsmoduls noch vor dessen
Auslieferung an einen Kunden, also vorzugsweise während oder im Anschluss an die Fertigung am Bandende, auf einem
geeigneten Speicher abgelegt, bspw. auf einem ROM, einem EEPROM oder einem Flash-Speicher. Der Speicher kann in das Rechengerät integriert (interner Speicher) oder außerhalb des Rechengeräts angeordnet sein (externer Speicher) . Nach der Auslieferung des Verbindungsmoduls an den Kunden (d.h. den Hersteller des Sensors) , kann dieser dann einen anderen Teil des Computerprogramms frei programmieren und auf einem internen oder externen Speicher des Rechengeräts ablegen.
Dabei kann es sich um denselben Speicher handeln, auf dem bereits der fest vorgegebene Teil des Computerprogramms abgelegt ist (vorzugsweise jedoch in einem anderen
Speicherbereich) , oder aber es handelt sich um einen
separaten Speicher.
Das Verbindungsmodul wird auch als Tactical Service Bus
Interface (TSBI) bezeichnet. Das TSBI arbeitet als ein
Verbindungsmodul, welches die den einzelnen Sensoren
zugeordnete Firmware in SOA-kompatible Standards umwandelt. Das TSBI stellt Funktionalitäten als Services in
Übereinstimmung mit den Web Service-Standards zur Verfügung. Des Weiteren stellt das TSBI die meisten üblichen
Schnittstellen als Hardwareschnittstellen zur Verfügung, über die das TSBI mit dem mindestens einen Sensor einerseits und dem SOA-Netzwerk andererseits verbunden ist. Die Schnittstelle zum SOA-Net zwerk kann bspw. als eine Funk- Schnittstelle ausgebildet sein, die beispielsweise durch einen digitalen Signalprozessor (DSP) gesteuert wird. Dadurch kann eine weitgehend verzögerungsfreie Datenübertragung zwischen dem TSBI und dem SOA-Netzwerk erreicht werden.
Vorzugsweise bietet das TSBI zwei Schnittstellenarten an, eine SOA-Schnittstelle zu den Enterprise Service Busses
(ESBs) und eine Funk-Schnittstelle, die durch ein separates Lightweight Service Bus Node (LSBN) -Modul realisiert wird. Somit ist das TSBI in der Lage, insbesondere Sensoren aus dem Bereich der Sicherheits- und Verteidigungstechnik
(sogenanntes Legacy Equipment) in ein SOA-Umfeld zu
integrieren. Die Erfindung hat den Vorteil, dass die
Entwicklung völlig neuer, SOA-fähiger Sensoren nicht
erforderlich ist. Vielmehr können herkömmliche, an sich nicht-SOA-fähige Sensoren verwendet werden, wobei diese - wie gesagt - mittels des TSBI generisch SOA-fähig gemacht werden.
Der vorliegenden Erfindung liegt also die Idee zugrunde, einen oder mehrere an sich nicht SOA-fähige Sensoren
beliebiger Bauart mittels des (bis auf den vom
Sensorhersteller zu programmierenden Teil des
Computerprogramms) weitgehend standardisierten
Verbindungsmoduls auf einfache und kostengünstige Weise SOA- Fähigkeit zu vermitteln, um die Sensoren so in eine SOA- Net zwerk-Struktur integrieren zu können. Die Integration der Sensoren über das Verbindungsmodul ist wesentlich
kostengünstiger, einfacher und schneller als die komplette Neuentwicklung des gesamten Sensors mit integrierter SOA- Fähigkeit. Durch die Erfindung wird die Akzeptanz und damit auch die Verbreitung von SOA-fähigen Netzwerken im Bereich der Sicherheits-, Wehr- und Verteidigungstechnik deutlich ansteigen. Das ist besonders interessant für alle Arten von Einsatzkräften, wie z.B. Polizei, Bundesgrenzschutz,
Feuerwehr, Technisches Hilfswerk, Bundeswehr, medizinische Notfallversorgung etc. Ein wichtiger Aspekt der vorliegenden Erfindung ist darin zu sehen, dass eine generische Kapselung beliebiger Geräte (z.B. Sensoren, Aktuatoren oder Effektoren) zur Verfügung gestellt wird, das heißt eine Abbildung beliebiger an sich nicht-SOA- fähiger Geräte in einem SOA-Umfeld ermöglicht wird. Die
Kapselung ist möglich, ohne dass der Hersteller des zu kapselnden Geräts über Wissen bezüglich des SOA-Umfelds und des SOAP (Simple Object Access Protocol) verfügt.
Insbesondere muss der Gerätehersteller nicht über
Informationen bezüglich einer sog. Zustandsbehaftung
(stateful) der Geräte und Zustandslosigkeit (stateless) der Services und deren Berücksichtigung beim Konsumieren der Services verfügen. Zustandsbehaftung bedeutet, dass sich das Gerät oder die Kapselung Informationen über den eigenen
Zustand abspeichert. Zustandslosigkeit bedeutet, dass der Dienst (d.h. SOA Webservice) mehrere Anfragen grundsätzlich als voneinander unabhängige Transaktionen behandelt; keine Informationen werden zwischen Abfragen gespeichert. Wenn das zu kapselnde Gerät bspw. eine drehbare Waffe ist, kann diese mit einem ersten Befehl in die gewünschte Position gedreht und mit einem zweiten Befehl abgefeuert werden. Wenn man nun den dem zweiten Befehl entsprechenden Service unmittelbar nach dem ersten Service absetzen würde, könnte dies bei unsachgemäßer Verarbeitung dazu führen, dass die Waffe abgefeuert wird noch bevor die gewünschte Position erreicht ist. Hier schafft das TSBI Verbindungsmodul Abhilfe, indem bspw. Service-Anforderungen (sog. Requests) abgespeichert und koordiniert abgearbeitet werden können. Falls gewünscht, kann das Verbindungsmodul sogar Prioritäten in SOAP-Anfragen berücksichtigen und bei der Abarbeitung der Befehle
berücksichtigen. Dazu erzeugt eine Web Service Schnittstelle (ein sog. Request-Response Modul) des Verbindungsmoduls aus den SOAP-Anfragen Threads und sorgt für die richtige
Reihenfolge der Abarbeitung entsprechend den Prioritäten. Der Gerätehersteller muss auch keine Kenntnisse über Web
Services haben und nicht über Informationen oder Wissen über die Art eines verwendeten Service Busses (z.B. ein Enterprise Service Bus (ESB) vom Typ Websphere, vom Typ SOPBERA 3.3 oder vom Typ SOPERA „Swordfish" oder eines anderen Typs oder ein Lightweight Service Bus (LSB) ) verfügen. Das erfindungsgemäße Verbindungsmodul stellt auf Anfrage durch den Anwender je nach Art des verwendeten Service Busses selbsttätig eine passende WSDL (Web-Service Definition Language) -Datei zur Verfügung, welche in die Registry des Service Busses geladen wird .
Ein wichtiger Aspekt des TSBI Verbindungsmoduls ist die
Existenz einer Heartbeat-Funktion. Heartbeats ermöglichen auf SOA Ebene zu wissen, ob eine Kapselung noch aktiv ist und sich korrekt verhält oder bspw. aufgrund eines Fehlers nicht mehr aktiv ist. Heartbeat-Funktionen werden für jede neue Kapselung automatisch generiert. Diese Funktionen werden von Zeit zu Zeit automatisch aufgerufen. Jeder erfolgreiche automatische Aufruf einer Heartbeat-Funktion löst eine neue Notifikation aus (publish) , die auf SOA Ebene durch
Abonnieren (subscribe) bei dem sog. Notification Provider des Verbindungsmoduls empfangen werden kann. Der Gerätehersteller hat die Möglichkeit die Heartbeat-Funktion zu implementieren. Dabei stellt er sicher, dass der Sensor/Effektor, der
gekapselt ist, auch aktiv und verfügbar ist und sich korrekt verhält. Ein nicht aktiver Sensor, Effektor oder eine nicht aktive Kapselung hat ein Ausbleiben" der Heartbeat-Nachricht zur Folge. Ein Watchdog-Timer lauscht auf Heartbeat- Nachrichten. Beim Ausbleiben von Beartbeat-Nachrichten löst der Watchdog-Timer einen Neustart der verantwortlichen
Kapselungs-Software aus.
Gemäß einer vorteilhaften Weiterbildung der Erfindung wird vorgeschlagen, dass das Verbindungsmodul eine erste Moduleinheit, welche den angeschlossenen Sensor, Effektor oder Aktuator als einen Dienst im SOA-Netzwerk abbildet, sowie eine zweite Moduleinheit umfasst, welche den durch die erste Moduleinheit abgebildeten Dienst für eine Übertragung über ein Funknetz mit niedriger Bandbreite unter Beibehaltung der SOA-Funktionalität aufbereitet. Die erste Moduleinheit wird auch als Vendor Device Encapsulator (VDE) bezeichnet. Die zweite Moduleinheit wird auch als Lightweight Service Bus Node (LSBN) bezeichnet.
Der VDE dient zur Kapselung eines beliebigen nicht-SOA- fähigen Geräts als Web-Service, der von dem vorhandenen
Service Bus erkannt und verwaltet (man spricht im
Zusammenhang mit Services auch vom sog. Orchestrieren von Services) werden kann. Der VDE generiert einen Service, auf den über ein Request-Response-Modul des VDE (z.B. im SOAP) und über ein Publish/Subscribe-Modul des VDE (z.B. im JMS- Format, Java Messaging Service) zugegriffen werden kann. Der VDE hostet die Service Kapselung in einem abgeschlossenen Bereich des VDE, der sog. Sandbox, wodurch verhindert wird, dass eventuelle Fehlfunktionen des Service oder des
gekapselten Geräts das Host-System (das Betriebssystem des Verbindungsmoduls bzw. des VDE) beeinträchtigen. Die Sandbox sorgt auch dafür, dass das intellektuelle Eigentum des
Geräteherstellers geschützt ist. D.h., dass der Anwender oder eine böswillige Person keine Möglichkeit hat, auf die
Software und den Quellcode, die/den der Hersteller in dem TSBI installiert hat, zuzugreifen. Der VDE bietet eine
Vielzahl unterschiedlicher Schnittstellen zum Anschlüsse von zu kapselnden Geräten für einen Service. Die mit dem VDE erzeugten Services sind in einer Service Registry des VDE gespeichert. In Abhängigkeit von den Eigenschaften und
Fähigkeiten des Services Busses stellt die Service Registry unterschiedliche Abbildungen oder Darstellungsweisen (sog. Repräsentation) des Services, z.B. in WSDL, zur Verfügung, wobei die Repräsentation des Services nicht notwendigerweise den WS-I (Web Services Interoperability Organization)
Empfehlungen entsprechen muss. Dies macht es theoretisch möglich, dass ein generierter Service durch jeden beliebigen Service Bus referenziert werden kann.
Durch den LSBN (Lightweight Service Bus Node) wird der
Einsatz des Verbindungsmoduls in der militärischen Welt ermöglicht bzw. verbessert. Ein LSB (Lightweight Service Bus) ist ein völlig verteilter Service Bus. Der Begriff LSB bezeichnet kein Gerät, sondern eine Abstraktion von mehreren LSBNs, die miteinander vernetzt sind. Mit dem LSB wird ein Service Bus vorgeschlagen, der an die Anforderungen in der militärischen Welt angepasst ist. Diese Anforderungen
umfassen bspw. besondere Sicherheitsmechanismen, niedrige Übertragungsraten über (Funk-) Übertragungsstrecken.
Im Unterschied zu dem aus der IEEE-Veröffentlichung „Service- Oriented Sensor Data Interoperability for IEEE 1451 Smart Transducers" bekannten Verbindungsmodul setzt das TSBI bzw. der VDE nicht voraus, dass die zu kapselnden Systeme
Transducer sind bzw. solche umfassen. Die Erfindung kann ein SOA-Interface für jegliche Art von System zur Verfügung stellen. Das TSBI bzw. der VDE setzt keine bestimmte Art von Protokoll oder Technologie voraus, um mit dem System
kommunizieren zu können. Das TSBI bzw. der VDE ist ein
Rahmen, der es erlaubt, eine Definition zu generieren, die für alle durch das System zur Verfügung gestellte Operationen (z.B. turnLeft, getPicture, ...) passend ist. Ein Rahmen für den entsprechenden Programmcode wird anhand einer Definition des einzubindenden Systems generiert. Der Hersteller des zu kapselnden Systems füllt den Rahmen mit entsprechenden
Funktionen im Quellcode und interagiert mit dem System in einer Weise, wie er es wünscht. Wenn der Hersteller mit diesem Schritt fertig ist, kompiliert er den Quellcode in einen Binärcode und importiert diesen in den TSBI bzw. in den VDE. Das TSBI bzw. der VDE werden den Binärcode verwenden, um mit dem gekapselten System zu kommunizieren und um automatisch ein Web Service Interface für eine beliebige Art von SOA-Umfeld (Bus, Client, Web-Service-Interface-konform oder nicht) zu generieren. Das TSBI bzw. der VDE erlaubt es ein SOA-Interface für einen Sensor zu generieren, ohne dass konkretes Detail-Wissen über die SOA-Umgebung vorhanden sein muss .
Im Unterschied zu dem aus der IEEE-Veröffentlichung „Open Sensor Web Architecture : Core Services" bekannten
Verbindungsmodul baut das TSBI eine direkt Verbindung zu den einzubindenden Systemen auf. Der VDE bzw. das TSBI setzt keinen besonderen Standard und kein besonderes Protokoll voraus, um mit dem System interagieren zu können. Der VDE ist keine Architektur, sondern ein Rahmen, der es erlaubt, ein SOA-Interface zum Anbinden beliebiger Systeme in das SOA- Umfeld zu generieren, unabhängig davon, welches Interface die Systeme haben. Das der VDE auch heterogene Systeme kapseln kann, wird der VDE auch als generische Kapselungsvorrichtung („generic encapsulator" ) bezeichnet. Anders als bei dem bekannten NICTA-Verfahren, erfordert die Kapselung eines Systems bei der vorliegenden Erfindung kein Wissen über SOA oder Web Services. Das TSBI stellt auch erweiterte
Funktionalitäten zur Verfügung, die bei dem bekannten
Verbindungsmodul nicht erwähnt sind. Dies ist bspw. eine sog. „Heartbeat"-Funktion, um sicherzustellen, dass die
Kapselungssoftware und das gekapselte Gerät (Sensor oder Effektor) noch aktiv und verfügbar ist, ein sog. „traffic shaping", um das Netzwerk gegen eine vom Sensor ausgesandte ungewöhnlich große Datenmenge zu schützen, oder ein sog.
„sandboxing" , um zu verhindern, dass trotz eines fehlerhaften Verhaltens des Systems, bspw. aufgrund eines fehlerhaften Sensors, einer fehlerhaften Kapselung im VDE und/oder einer fehlerhaften Konfiguration des VDE, der TSBI scheinbar normal und ordnungsgemäß funktioniert. Der TSBI setzt keine Modell-Sprache für die Darstellung der Daten voraus; er unterstützt jede Art von XML Darstellung und Verschlüsselung. Der TSBI ist auf einen Einsatz in einer militärischen Umgebung besonders gut vorbereitet. Alle
Komponenten (Sensoren, Aktuatoren, Effektoren) sind verteilt (z.B. hat jeder Knoten eine eigene Registry), so dass eine Fehlfunktion eines Knotens nicht zu einer Fehlfunktion des gesamten Sensor-Netzwerks führt. Das TSBI stellt zwei
Schnittstellen zur Verfügung, um mit den gekapselten Systemen interagieren zu können, nämlich eine Request/ Response- Schnittstelle sowie eine Publish/ Subscribe-Schnittstelle . Für die Notifikation nutzt das TSBI vorzugsweise nicht
Nutzer-Registrierungen für ein Abonnement, sondern sog.
Topics (Themen, Identifikationen) . In einem militärischen Zusammenhang sind alle Services verteilt.
Anders als das bekannte NICTA-Verbindungsmodul , vermischt das TSBI nicht die AblaufVerwaltung (sog. „Orchestration" ) der Services, den Service Bus und die SOA System-Kapselung . Das VDE stellt eine statische SOA-Kapselung für ein System zur Verfügung, der militärische Lightweight Service Bus Node (LSBN) oder ein anderer Enterprise Service Bus (ESB) stellt die Bus-Infrastruktur zur Verfügung und möglicherweise auch AblaufVerwaltungs-Fähigkeiten . Eine Service Verbraucher Logik auf der Seite des Client kümmert sich um die AblaufVerwaltung der Services. Das TSBI zielt auch darauf ab, eine
Schnittstelle zwischen dem System (Sensor, Aktuator und/oder Effektor) und einem beliebig ausgebildeten Bus zu sein. Da der SOA Web Service nicht manuell entwickelt wird, sondern durch den Rahmen (das Bezugssystem, sog. Framework)
automatisch generiert wird, ist es möglich, jegliche Art von WSDL-Darstellung, die theoretisch möglich ist, vorzuschlagen, die in einem beliebigen Service-Bus dargestellt werden kann, selbst wenn diese nicht die Vorgaben der Web Service
Interoperability Darstellung erfüllt. Die vorliegende Erfindung betrifft also die Kapselung von nicht Service orientierten Systemen, um auf die
Funktionalitäten bzw. Systemfähigkeiten über Web-Service konforme Schnittstellen zugreifen zu können. Das TSBI
zeichnet sich insbesondere dadurch aus,
dass das Verbindungsmodul einen generischen Web-Service- Anteil beinhaltet, der nach außen Web-Service konforme Schnittstellen anbietet. Das Verbindungsmodul kann auch nicht-Web-Service konforme Schnittstellen anbieten, so dass aktuelle Enterprise Service Busses (ESBs) , die nicht zu 100% den Standards entsprechen oder proprietäre Funktionsmerkmale (sog. Features) haben, den Dienst ebenfalls konsumieren können.
dass das TSBI eine Schnittstellenkomponente beinhaltet, die in Abhängigkeit von dem anzuschließenden System (den Sensor) instanziiert werden muss und die auf der anderen Seite an den Web-Service-Anteil (das SOA-Netzwerk) angeschlossen ist,
dass das TSBI eine Schnittstelle zum Generieren einer SOA-Schnittstelle nach außen und eines Gerüsts zur
Realisierung einer Kapselung des Sensors beinhaltet. Diese Kapselung kann danach außerhalb des TSBI mit Hilfe einer passenden Entwicklungsumgebung implementiert, das heißt abhängig von dem Typ des zu kapselnden Sensors „mit Leben gefüllt" werden. Durch die
Entwicklungsumgebung ist es dem jeweiligen Hersteller des anzuschließenden Systems (Sensorhersteller)
ermöglicht, die Erfindung in Abhängigkeit von dem angeschlossenen System zu instanziieren ,
dass die Erfindung in einem separaten Gehäuse
untergebracht ist, das robust genug auch für raue
Einsatzumgebungen ist.
Alternativ zu der Anordnung des TSBI in einem separaten Gehäuse ist auch die Ausgestaltung des TSBI als reine
Softwarelösung möglich. In diesem Fall würde eine auf einem beliebigen Rechner (z.B. einem Personal Computer, PC)
ablauffähige Software derart programmiert werden, dass sie eine Kapselung eines an den Rechner angeschlossenen nicht- SOA-fähigen Systems und die Integration des Systems in eine SOA-Umgebung realisieren kann, wenn sie auf dem Rechner bzw. auf einem Mikroprozessor des Rechners abläuft.
Die TSBI-Infrastruktur optimiert die Abläufe bezüglich taktischer Operationen bei gleichzeitig deutlich beschränkten Funk- oder Netzwerkbeschaffenheit. Dies wird erreicht durch besonders fortschrittliche Datenkompressionsverfahren,
Anpassungen des Datenübertragungsprotokolls und eine
deutliche Verringerung hinsichtlich des Datendurchsatzes.
Die TSBI-Infrastruktur erfüllt höchste
Mobilitätsanforderungen und stellt die Verfügbarkeit sicher, selbst wenn einige Sensoren defekt sind. Deshalb ist ein Zusammenbruch des gesamten SOA-Systems verursacht bspw. durch einen einzigen defekten Sensor, einen Defekt in einer
Kapselung oder in der Konfiguration des Verbindungsmoduls (sogenannter Single Point of Failure) , praktisch
ausgeschlossen.
Das TSBI stellt eine Hochleistungsplattform dar, die eine schnelle, einfache und kostengünstige Realisierung einer SOA- Infrastruktur innerhalb bereits existierender oder in
Anwendung befindlicher Systeme dar. Die bekannten, nicht-SOA- fähigen Systeme können somit schnell und einfach in
zukünftige SOA-Systeme integriert werden.
Für den Anwender ergibt sich durch den Einsatz des
erfindungsgemäßen Verbindungsmoduls ein deutlicher
Kostenvorteil, da die Kosten für das Verbindungsmodul sowie für die Programmierung des programmierbaren Teils des
Computerprogramms, das die Verbindung zwischen der Firmware des Sensors einerseits und dem fest vorgegebenen Teil des Computerprogramms deutlich geringer sind als die Kosten, die ein komplett neuer SOA-fähiger Sensor erzeugen würde. Bei dem TSBI handelt es sich um ein Standard-Verbindungsmodul
(sogenannte Of the shelf SOA Platform) , die herkömmliche, an sich nicht-SOA-fähige Sensoren um eine SOA- Fähigkeit
erweitert .
In dem vom Sensorhersteller frei programmierbaren
Computerprogramms des Verbindungsmoduls hat der
Sensorhersteller die Möglichkeit, auf einfache und
kostengünstige Weise Algorithmen und Abläufe zu integrieren, damit die Firmware des Sensors an die SOA-Umgebung angepasst wird. Die SOA-Umgebung beziehungsweise die Art und Weise wie SOA-Prozesse behandelt werden, kann von einer übergeordneten Organisation, beispielsweise von der NATO (North Atlantic Treaty Organisation) , dem IT-Amt der Bundeswehr, dem
Bundesjustizministerium oder dem Bundesinnenministerium, vorgegeben sein. Dabei wird der Sensor beziehungsweise dessen Funktionalität als Dienst im SOA-Umfeld abgebildet.
Es ist denkbar, dass ein erfindungsgemäßes Verbindungsmodul (TSBI) nicht nur einem Sensor, sondern einer Vielzahl von Sensoren zugeordnet ist. Ebenso ist es denkbar, dass ein Sensor nicht nur einen Detektor, sondern mehrere Detektoren aufweist. Dadurch ist es beispielsweise möglich, dass ein Sensor mittels einer Kamera ein zu überwachendes räumliches Gebiet erfassen, mittels eines Geophons Erschütterungen detektieren und mittels eines Thermometers eine Temperatur erfassen kann. Bei solchen Multisensorsystemen sind die einzelnen Detektoren über einen Sensorknoten an die erste Schnittstelle des TSBI angeschlossen. Verschiedene Sensoren können auch direkt an das Verbindungsmodul angeschlossen werden .
Über das SOA-Umfeld können die Informationen und Daten verschiedener Detektoren und Sensoren zusammengeschaltet und dem Anwender auf einer einheitlichen Oberfläche ausgegeben werden. Außerdem ist es möglich, dass der Anwender über das SOA-Netzwerk Zugriff auf die über das TSBI an das SOA- Netzwerk angekoppelten Sensoren erhält, um diese
beziehungsweise deren Detektoren anzusteuern. So ist es beispielsweise denkbar, dass der Anwender über das SOA- Netzwerk die Blickrichtung einer Kamera steuern kann. Es ist möglich, dass die in einem SOA-Umfeld gesammelten
Informationen und Daten mehreren Anwendern auf verschiedenen Oberflächen präsentiert werden. Die Ansteuerung der Sensoren über das SOA-Netzwerk kann jedoch immer nur von einem der Anwender erfolgen.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung können den Unteransprüchen entnommen werden. Weitere Merkmale und Vorteile der Erfindung sind in der nachfolgenden
Figurenbeschreibung beschrieben, wobei die genannten Merkmale und Vorteile nicht nur in der beschriebenen Kombination, sondern auch in Alleinstellung vorhanden sein können. Es zeigen :
Figur 1 eine SOA-Net zwerk-Struktur ;
Figur 2 ein erfindungsgemäßes Verbindungsmodul gemäß einer ersten bevorzugten Ausführungsform;
Figur 3 eine Prinzipdarstellung der Kombination eines
herkömmlichen Sensors mit dem erfindungsgemäßen Verbindungsmodul ;
Figur 4 ein erfindungsgemäßes Verbindungsmodul gemäß einer weiteren bevorzugten Ausführungsform;
Figur 5 das Prinzip eines Generierens einer SOA Kapselung eines Sensors anhand des Verbindungsmoduls aus Figur 4; Figur 6 das Prinzip einer Kommunikation zwischen einem
Client Computer aus der SOA-Umgebung und einem gekapselten Sensor anhand des Verbindungsmoduls aus Figur 4 ;
Figur 7 das Prinzip einer Nachrichtenübermittlung zwischen dem einem Client Computer aus der SOA-Umgebung und einem gekapselten Sensor anhand des
Verbindungsmoduls aus Figur 4;
Figur 8 das Prinzip einer Nutzung von Services in einer SOA- Umgebung über ein Netzwerk mit beschränkter Bandbreite anhand des Verbindungsmoduls aus Figur 4 ;
Figur 9 eine perspektivische Ansicht eines erfindungsgemäßen
Verbindungsmoduls; und
Figur 10 das Prinzip der erfindungsgemäßen Kapselung eines
Geräts .
Figur 1 zeigt eine SOA-Net zwerk-Struktur , wie sie bspw. im Bereich der Sicherheits- und/oder Verteidigungstechnik eingesetzt werden kann. Die SOA-Net zwerk-Struktur ist in ihrer Gesamtheit mit dem Bezugszeichen 1 bezeichnet. Die Struktur 1 umfasst zunächst mehrere Sensoren 2, die mit Sl, S2, ... Sn bzw. Sl, S2, ... Sm bezeichnet sind, wobei n und m natürliche Zahlen > 1 sind. In den nachfolgenden Ausführungen wird der Einfachheit halber nur auf Sensoren Bezug genommen. Die Ausführungen gelten in entsprechender Weise jedoch auch für Effektoren (z.B. beliebige Waffensysteme) und Aktuatoren (z.B. beliebige Antriebssysteme).
In dem beschriebenen Ausführungsbeispiel sind die Sensoren 2 bspw. als Kameras zum Erfassen eines räumlichen Bereichs, Geophone zum Detektieren von Erschütterungen, als Temperatursensoren zum Erfassen von Temperaturen, als
Drucksensoren zum Erfassen eines Druckes oder als beliebig andere Sensoren ausgebildet, welche Informationen über ein zu überwachendes räumliches Gebiet, ein zu überwachendes
Einsatzfahrzeug oder ähnliches liefern. Die Sensoren 2 sind an sich nicht SOA-fähig.
Die Sensoren 2 sind an erfindungsgemäße Verbindungsmodule 3 angeschlossen, welche den Sensoren 2 eine SOA-Fähigkeit vermitteln. Die Verbindungsmodule 3 werden auch als Tactical Service Bus Interface (TSBI) bezeichnet. In dem
Ausführungsbeispiel sind jeweils mehrere Sensoren 2 an ein Verbindungsmodul 3 angeschlossen. Es ist jedoch auch denkbar, dass lediglich ein Sensor 2 an ein Verbindungsmodul 3
angeschlossen ist. In dem Ausführungsbeispiel sind die
Verbindungsmodule mit TSBIl und TSBIp bezeichnet, wobei p eine natürliche Zahl > 1 ist. Die TSBIs 3 sind vorzugsweise in der Nähe der Sensoren 2 angeordnet. Wenn die Sensoren bspw. auf einem Einsatzfahrzeug angeordnet sind, wäre ein TSBI 3 vorzugsweise ebenfalls auf dem Fahrzeug angeordnet. Der Anschluss der Sensoren 2 an die TSBIs 3 erfolgt
vorzugsweise über erste Schnittstellen 3.2. Die ersten
Schnittstellen 3.2 sind vorzugsweise als RS232- und/oder LAN- Schnittstellen ausgebildet.
Die Verbindungsmodule 3 sind ihrerseits an eine
Kommunikations-Infrastruktur 4 angeschlossen. Diese kann als eine beliebige Busstruktur, über die Datennachrichten nach einem bestimmten Busprotokoll übertragen werden, oder
ähnliches ausgebildet sein. Die Busstruktur 4 ist bspw. ein CAN- oder ein TTCAN-Bus. Die Kommunikations-Infrastruktur 4 kann leitungsgebunden oder schnurlos, insbesondere über Funk, realisiert sein. Die Infrastruktur 4 kann als eine beliebige Datenübertragungsverbindung, bspw. als eine Funkverbindung, von den TSBIs 3 zu einer Vermittlungsstelle ausgebildet sein, über die Zugang zum Internet/ zu einem Intranet besteht. Bei diesem Ausführungsbeispiel würde die Infrastruktur 4 also durch die Datenübertragungsverbindungen und das Internet/ Intranet gebildet. Der Anschluss der Kommunikations- Infrastruktur 4 an die TSBIs 3 erfolgt vorzugsweise über zweite Schnittstellen 3.4. Diese sind vorzugsweise als
Funkschnittstellen ausgebildet. Durch den Zugang zum
Internet/ Intranet ist es möglich, auf Sensor-/ Effektor- Kapselungen zuzugreifen, die in einem Repository eines
Servers liegen. Diese Kapselungen können heruntergeladen und auf dem TSBI installiert werden.
Schließlich verfügt die SOA-Net zwerk-Struktur 1 über Anwender (sog. user) 5, die an die Kommunikations-Infrastruktur 4 angeschlossen sind. Die Anwender sind mit Ul, U2, Uo bezeichnet, wobei o eine natürliche Zahl > 1 ist. Die
Anwender 5 sind bspw. über internetfähige Computer an das Internet 4 angeschlossen. Die Computer bieten den Anwendern 5 vorzugsweise jeweils eine Ausgabeeinrichtung (z.B. einen Bildschirm, einen Drucker, etc.) zur Ausgabe von
Informationen und eine Eingabeeinrichtung (z.B. eine
Tastatur, eine Maus, einen Trackball, etc.) zur Eingabe von Informationen und Befehlen.
In Figur 2 ist ein erfindungsgemäßes TSBI 3, wie bspw. das TSBI1 oder das TSBIp, im Detail dargestellt. Es umfasst zunächst mindestens einen Programm- und/oder Datenspeicher 6, der bspw. als ein ROM, ein EEPROM oder ein Flash-Speicher ausgebildet sein kann. In dem Speicher 6 ist ein
Computerprogramm abgespeichert, welches in einem Rechengerät 7 des TSBI 3 abgearbeitet wird. Das Rechengerät 7 ist
vorzugsweise als ein Mikroprozessor ausgebildet. Es ist aber auch denkbar, dass das Rechengerät 7 als ein digitaler
Signalprozessor (DSP) oder ähnliches ausgebildet ist. Das Rechengerät 7 kann auch die Funktionsabläufe an den
Schnittstellen 3.2 und/oder 3.4 koordinieren und steuern. Das in dem Speicher' 6 abgelegte Computerprogramm ist in mindestens zwei Abschnitte 8.1 und 8.2 unterteilt, die in unterschiedlichen Speicherbereichen 6.1 und 6.2 des Speichers 6 abgelegt sind. In dem beschriebenen Ausführungsbeispiel ist in einem dritten Speicherbereich 6.3 kein Computerprogramm abgelegt; dieser Speicherbereich 6.3 ist in diesem
Ausführungsbeispiel also frei. Selbstverständlich kann auch dort ein Abschnitt 8.1 und/oder 8.2 des Computerprogramms abgelegt sein. Außerdem kann auf den freien Speicherbereich 6.3 auch verzichtet werden.
Ein erster Abschnitt 8.1 des Computerprogramms umfasst diejenigen Teile des Computerprogramms, die Standard-Abläufe betreffen. Dies können bspw. Abläufe sein, welche die
Ansteuerung und Funktionsweise der Schnittstellen 3.2 und 3.4 betreffen. Außerdem kann der erste Abschnitt 8.1 des
Computerprogramms die bspw. von der NATO festgelegten
Vorgaben betreffen, wie die einzelnen SOA-Prozesse und - Dienste in der SOA-Net zwerk-Struktur 1 behandelt werden. Der erste Abschnitt 8.1 des Computerprogramms wird vom Hersteller des TSBI 3 vorgegeben und während oder im Anschluss an die Herstellung des TSBI 3 am Bandende programmiert. Erst danach wir der TSBI 3 an die Kunden, d.h. an die Hersteller der Sensoren 2, ausgeliefert.
Die Sensorhersteller entwickeln und programmieren dann einen anderen Abschnitt 8.2 des Computerprogramms und legen diesen in dem dafür vorgesehenen Speicherbereich 6.2 im Speicher 6 ab. Die vom Sensorhersteller programmierte Software stellt eine Verbindung zwischen der üblicherweise proprietären
Sensor-Firmware und dem vorgegebenen und in weiten Teilen standardisierten SOA-Umfeld her. Bei der Programmierung kann der Sensorhersteller auf den bereits vom Hersteller des TSBI 3 entwickelten Abschnitt 8.1 des Computerprogramms aufbauen. In der Programmierungs- und Implementierungsphase kann der Sensorhersteller vom Hersteller des TSBI 3 unterstützt werden. Auf diese Weise können die an sich nicht—SOA—fähigen Sensoren 2 einfach und schnell in die SOA-Umgebung integriert werden. Beide Abschnitte 8.1 und 8.2 bilden zusammen das Computerprogramm, das auf dem Rechengerät 7 des TSBI 3 abläuft, um die angeschlossenen Sensoren 2 in die SOA- Netzwerk-Struktur 1 zu integrieren.
In einem Anwendungsbeispiel ist bei einem Einsatz der
Bundeswehr im Ausland die Überwachung eines bestimmten
Planguadrats in dem Land von 10:00 bis 16:00 Uhr gefordert. Der Aufklärungseinsatz kann von den Anwendern 5 dezentral, d.h. bspw. von Deutschland aus, koordiniert und ausgewertet werden. Dazu steuert einer der Anwender 5 die Sensoren 2 in geeigneter Weise an. Dies kann bspw. über eine grafische Benutzerschnittstelle (sog. Graphical User Interface, GUI) erfolgen, das auf den Bildschirmen der den Anwendern 5 zugeordneten Computer dargestellt und mittels Tastatur, Maus o.ä. bedient werden kann.
Zu Beginn des Aufklärungseinsatzes ermittelt der Anwender 5, welche Sensoren 2 in dem vorgegebenen Planguadrat überhaupt zur Verfügung stehen. Ggf. kann ein Fahrzeug, eine Drohne o.ä. mit mindestens einem TSBI 3 und zusätzlichen Sensoren 2 während des vorgegebenen Zeitraums in das Planquadrat
befohlen werden. Über die SOA-Netzwerk-Struktur 1 würde der Anwender 5 dann Informationen erhalten, dass zusätzliche Sensoren 2 für den Aufklärungseinsatz zur Verfügung stehen. Der Anwender 5 kann die Sensoren 2 über den ihm zugeordneten Computer in gewünschter Weise ansteuern. Das umfasst zum einen die Aktivierung und Deaktivierung der Sensoren 2. Zum anderen umfasst dies aber auch ein gezieltes Steuern der Sensoren 2 während ihres Betriebs, um bspw. den
Erfassungsbereich einer Kamera verändern zu können. Auch eine Steuerung des Fahrzeugs, der Drohne o.ä. wäre denkbar. Am Beispiel eines Sensors 2 in Form eines Radargeräts umfasst das Ansteuern des Sensors 2 die Auswahl eines Sektors (eines Überwachungsbereichs) , eine Steuerung einer Scan-Funktion (Abtasten des Überwachungsbereichs) , einer Track-Funktion (Verfolgen eines Objekts im Überwachungsbereich) oder eines Schwenk-Neige-Kopfes, auf dem der Radarsensor befestigt ist.
Die Ansteuerbefehle des Anwenders 5 für einen Sensor 2 werden zunächst von dem fest vorgegebenen Teil 8.1 des
Computerprogramms aus dem SOA-Umfeld entnommen und in
entsprechende Rohdaten umgewandelt, die der vom
Sensorhersteller programmierte Teil 8.2 des Computerprogramms dann in entsprechende Ansteuersignale für den Sensor 2 umwandelt. In umgekehrter Richtung werden die Messwerte oder -Signale des Sensors 2 von dem frei programmierten
Softwareteil 8.2 in Rohdaten umgewandelt, die der fest vorgegebene Softwareteil 8.1 dann in das SOA-Umfeld
einbringt .
Jeder der Sensoren 2 kann über die SOA-Net zwerk-Struktur 1 nur von einem Anwender 5 angesteuert werden. Die erfassten und über die SOA-Net zwerk-Struktur 1 zur Verfügung gestellten Sensormesswerte können jedoch von mehreren Anwendern 5 erfasst werden. Die Anwender 5 können dann gleich mit der Auswertung der Sensormesswerte beginnen und so Pläne für das weitere Vorgehen in diesem Planquadrat, bspw. Angriffs- oder Verteidigungspläne, ausarbeiten.
Die Sensoren 2 bzw. deren Funktionalität werden als Dienste im SOA-Umfeld dargestellt. Dadurch ist das Erfassen und
Auswerten der Sensormesswerte sowie die Koordination und Steuerung von Einsätzen im Bereich der Sicherheits- und/oder Verteidigungstechnik wesentlich übersichtlicher und
einfacher. Der Grundgedanke, der der vorliegenden Erfindung zugrunde liegt, geht von an sich nicht-SOA-fähigen Sensoren 2 aus, die möglichst einfach, schnell und kostengünstig in das SOA-Umfeld eingebunden werden sollen. Dazu wird den Sensorherstellern eine möglichst offene Programmier- und
Entwicklungsumgebung zur Verfügung gestellt.
Figur 3 zeigt eine Prinzipdarstellung der vorliegenden
Erfindung, in der die Komponenten definiert sind, die jeweils Teil der Funktionalität übernehmen, um allen Anforderungen, die an den TSBI gestellt werden, nachzukommen. Die zentralen Komponenten sind dabei die Notification- und die Messaging- Engine, welche die Aufgaben hinsichtlich des Web-Service konformen Zugriffs übernehmen und mit der jeweiligen
Infrastruktur kommunizieren. Die Notification-Engine
übernimmt dabei die Aufgabe, unaufgefordert Meldungen an interessierte Nutzer auszusenden; sie repräsentiert somit das Publish/ Subscribe MEP (Message Exchange Pattern) . Die
Messaging-Engine ist für das Request-Response-MEP
verantwortlich, über das Anfragen (Requests) an das Device in einem korrespondierenden Format beantwortet werden
(Response) .
Wenn in einer SOA-Umgebung (z.B. in dem Enterprise Service Bus) alle Dienste (Services) in einer zentralen Registry mit zugehörigen Metadaten registriert werden, muss der TSBI die Registrierung für das an ihn angeschlossene nicht Service orientierte System übernehmen. Der Konfigurationsblock übernimmt diese Aufgabe. Es ist aber auch denkbar, dass das' TSBI nicht die Registrierung für die angeschlossene SOA
Infrastruktur übernimmt, sondern lediglich eine passive
Schnittstelle anbietet, sodass die SOA Infrastruktur auf Metadaten und Dienstbeschreibungen (WSDL) zugreifen kann. In diesem Fall beinhaltet der TSBI eine Registry, in der alle ihm bekannten Dienste gespeichert sind. Der TSBI bietet eine Schnittstelle an, um diese Dienste abfragen zu können. Der TSBI übernimmt in diesem Fall nicht die Registrierung für das an ihn angeschlossene nicht Service orientierte System. Das System kann aber die Servicelisten beim TSBI abfragen und deren Inhalt zumindest ausschnittsweise in seine eigene
Registry eintragen.
Der Device-Controller (auch Kapselungs-Software genannt), der für das jeweilige anzuschließende nicht Service orientierte System implementiert werden muss, bildet die Schnittstelle zwischen dem Web-Service-Anteil und dem Legacy-Anteil .
Darüber hinaus ist eine Entwicklungsumgebung (IDE)
vorgesehen, die in der Abbildung nicht dargestellt ist. Diese dient dazu, den Device-Controller zu instanziieren . Diese IDE kann Teil des TSBI sein. Vorzugsweise beinhaltet der TSBI jedoch keine Entwicklungsumgebung, sondern bietet eine
Schnittstelle zum Generieren einer SOA-Schnittstelle nach außen und eines Gerüsts zur Realisierung einer Kapselung des Sensors an. Diese Kapselung kann danach außerhalb des TSBI mit Hilfe einer passenden Entwicklungsumgebung implementiert, das heißt abhängig von dem Typ des zu kapselnden Sensors „mit Leben gefüllt" werden. Die IDE ist derart ausgebildet, dass jeder Hersteller eines einzubindenden Systems aus einem vorgegebenen Gerüst den Device-Controller erzeugen kann. Mit ESB ist in Figur 3 ein Enterprise Service Bus und mit LSB ein Lightweight Service Bus bezeichnet. WS bezeichnen die Web- Services, WSDL eine Web-Service Definition Language und XSD eine XML Schema Datei.
Figur 4 zeigt ein weiteres bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung. Hierbei ist die Aufteilung des Verbindungsmoduls 3 in zwei Moduleinheiten hervorzuheben, nämlich einen sog. Vendor Device Encapsulator (VDE) und einen sog. Lightweight Service Bus Node (LSBN) . Der VDE bildet den angeschlossenen Sensor 2 als einen Dienst im SOA-Netzwerk 4 ab. Der LSBN bereitet den durch die erste Moduleinheit (VDE) abgebildeten Dienst für eine Übertragung über ein Funknetz mit niedriger Bandbreite („Radio") unter Beibehaltung der SOA-Funktionalität auf. Das TSBI kann entweder nur den VDE oder aber eine Kombination von VDE und LSBN aufweisen.
Das TSBI ist eine physikalische Einrichtung, welche die beiden Moduleinheiten hostet. Der VDE 10 ist vorzugsweise als ein Softwaresystem realisiert, das es erlaubt, für einen Sensor 2 eine SOA-Schnittstelle zu generieren. Als Sandbox 11 ist eine räumlich und funktional beschränkte Umgebung
bezeichnet, die sämtliche Sensor 2 SOA Kapselungen („Vendor Device SOA encapsulation") und Software beinhaltet, welche der Sensor 2 benötigt, um mit dem TSBI zu interagieren . Unter Sensor SOA Kapselung ist die Funktionalität bezeichnet, mit der die Funktionalität des Sensors 2 in der SOA-Umgebung abgebildet wird. Die Sandbox 11 dient auch zum Schutz des Host-Systems (TSBI) vor möglichen Angriffen oder (Software-) Fehlern und sorgt dafür, dass das intellektuelle Eigentum des Geräteherstellers in Form der programmierten Kapselungen geschützt ist. D.h., dass der Anwender oder eine böswillige Person keine Möglichkeit hat, auf die Software und den
Quellcode, die bzw. den der Hersteller in dem TSBI
installiert hat, zuzugreifen. Der „Vendor Device
Encapsulation Container" 12 dient als ein Behälter für die Sensor Kapselungen, die mit dem VDE erzeugt wurden. Die „Vendor Custom Software" 13 ist eine Sammlung von Software und Daten, die von den Sensor Kapselungen benötigt werden, um mit dem oder den Sensoren 2 interagieren zu können.
Mit Heartbeat 14 sind Heartbeat-Nachrichten bezeichnet, die veranlasst durch die Sensor Kapselungen ausgesendet werden um sicherzustellen, dass sich die Sensor Kapselungen korrekt verhalten. Eine Sensor Kapselung verhält sich korrekt, wenn sich der Sensor 2, der Bus 4 und der SOA Web Service korrekt verhalten. Mit Watchdog Timer 15 ist ein Modul bezeichnet, das sicherstellt, dass alle Sensor Kapselungen, die in der Sandbox 11 enthalten sind, am Laufen gehalten werden. Der Watchdog Timer 15 empfängt von den Kapselungen des Sensors 2 ausgesandte Heartbeat Nachrichten 14 und wertet diese aus. Falls eine Sensor Kapselung während einer definierten
Zeitdauer keine Heartbeat Nachricht aussendet, wird eine Fehlfunktion vermutet und der Watchdog Timer 15 startet die Sensor Kapselung von neuem, um ein längerfristiges Blockieren des Verbindungsmoduls 3 bzw. der Service Kapselung zu
verhindern. Der Watchdog Timer 15 sorgt also dafür, dass die Service Kapselung immer läuft und dass sich ein Fehler nicht auf das gesamte Verbindungsmodul 3 auswirkt und dieses evtl. außer Funktion setzt. Das Konzept des Service Heartbeat erlaubt es sicherzustellen, dass die Verarbeitung in Richtung von unten nach oben (Sensor/Aktuator/Effektor 2 - Service - Message Bus 16 - Web Service Schnittstelle 17, Pub/Sub
Schnittstelle 18) ohne Fehler abläuft. Zum Erhalt von
Heartbeat Nachrichten müssen sich der ESB 4 und/oder der LSBN 22 über das Pub/Sub-Modul 18 den Heartbeat-Service
abbonieren. Die abbonierten Service Busse (ESB 4 und/oder LSBN 22) erhalten dann von Zeit zu Zeit über das Modul 18 die Heartbeat Nachrichten.
Mit BUS 16 ist ein internes Bussystem (sog. Message Bus) bezeichnet, das die Sensor Kapselungen mit den SOA Web
Services Schnittstellen (Request-Response Interfaces 17 und Publish/ Subscribe Interfaces 18) verbindet. Der Sensor 2 Enkapsulations Generator 19 („Vendor Device Encapsulation Generator") erlaubt das Generieren von SOA Web Services und Quelltext (Source Code) Projekten, die - wenn sie einmal kompiliert sind - Sensor Kapselungen („Vendor Device SOA Encapsulations" ) ergeben. Ein Konfigurationsmodul 20
(„Configuration Module") erlaubt es, das Host System und die anderen Module des VDE 10 zu konfigurieren. Mit Service
Registry ist ein Modul 21 bezeichnet, das alle Sensor
Kapselungen auflistet, die auf dem TSBI 3 vorhanden sind. Die Service Registry 21 liefert heterogene WSDL-Dateien, um
Plattformen die Nutzung der Sensor Kapselungen zu
ermöglichen, selbst wenn die Plattformen nicht konform mit den WS-I (Web Services Interoperability Organization)
Empfehlungen sind. Die WSDL-Dateien sind individuell auf die Eigenschaften und die Funktionalität des Service Bus (z.B. ESB 4 oder LSBN 22) abgestimmt. Mit Request-Response
Messaging Provider 17 ist eine Schnittstelle bezeichnet, welche die Nutzung der Sensor Kapselungs Web Services mittels eines Request-Response Nachrichten Austausch Musters
(„Request-Response message exchange pattern") erlaubt. Mit Pub/Sub messaging provider ist eine Schnittstelle bezeichnet, welche die Nutzung der Sensor Kapselungs Web Services mittels eines Publish/ Subscribe Nachrichten Austausch Musters
(„Publish/ Subscribe message exchange pattern") erlaubt.
In den Modulen 17, 18 und 21 ist also praktisch das gesamte für die Kapselung erforderliche Wissen über die SOA-Umgebung, insbesondere über das SOAP, und über die Web Services
enthalten, so dass dieses nicht mehr wie bisher beim
Gerätehersteller vorgehalten werden muss, der die Kapselung des Geräts 2 realisiert. Dieser kann also die Kapselung des Geräts 2 ohne Wissen und Kenntnisse über die SOA-Umgebung, das SOAP und Web Services durchführen. Der Hersteller muss nur die Schnittstelle des zu kapselnden Geräts und die
Programmiersprache der Entwicklungsumgebung kennen. Dadurch ergibt sich die Möglichkeit einer besonders einfachen und Gerätehersteller-freundlichen Kapselung von Geräten 2 sowie ein flexible für unterschiedliche Geräte 2 einsetzbares
Kapselungsverfahren .
Mit Light Weight Service Bus (LSB) ist ein verteilter Service Bus bezeichnet, der eine SOA für taktische Netzwerke mit beschränkter Bandbreite (z.B. Funknetze) und bestimmte
Sicherheitsanforderungen zur Verfügung stellt. Der LSB umfasst einen oder mehrere LSB Einheiten (LSB Nodes; LSBNs) 22. Ein Request Response Modul 23 stellt eine Schnittstelle zu dem Request-Response Messaging Provider 17 des VDE 10 dar. Es übermittelt eingehende Request Nachrichten an den VDE 10 und nimmt Antwortnachrichten entgegen, welche den VDE 10 verlassen. Ein Publish/ Subscribe Modul 24 stellt eine
Schnittstelle zu dem Publish/ Subscribe Messaging Provider 18 des VDE 10 dar. Es übermittelt eingehende Anmeldungen an den VDE 10 und fängt Benachrichtigungsnachrichten ab, welche den VDE 10 verlassen.
Ein Service Discovery Modul 25 indiziert sämtliche Sensor Kapselungs Web Services, die auf dem VDE 10 vorhanden sind, und speichert die dazugehörigen Dienstbeschreibungen (z.B. WSDL) . Das Service Discovery Modul 25 ermöglicht die Abfrage der Dienstebeschreibungen, die sich auf dem LSBN 22' von anderen TSBIs 3' befinden (vgl. Figur 8). Da der TSBI 3 für den Einsatz in der taktischen bzw. militärischen Welt gedacht ist (z.B. beschränkte Bandbreite der Funknetze), erfolgt diese Synchronisation mit anderen LSBN 22 nicht automatisch. Die Synchronisation der TSBI 3 (Abfrage der
Dienstebeschreibungen von andere Knoten LSBN) findet vor dem Einsatz des TSBI (z.B. im Rahmen einer Mission Vorbereitung) oder während des Einsatzes als Ausnahme und auf explizite Anforderung einer dazu berechtigten Person, statt. Die ermittelten Dienstebeschreibungen werden in einem
Datenspeicher („Service Registry") 26 gespeichert. Dieses Diensteregister 26 ist völlig verteilt ausgebildet
(„Distributed Service Registry") weil es, im Gegensatz zu Enterprise Service Bussen (ESB) 4, hier kein zentrales
Diensteregister gibt. Das Wissen des LSBN 22 über Dienste besteht aus der Gesamtheit aller Dienstebeschreibungen, die im Diensteregister 26 jedes TSBI 3, 3' des Netzes abgelegt sind.
Nachfolgend werden verschiedene Module, wie „Compression" 27, „Encryption" 28, „Traffic Shaping" 29 und „Access Control" 30 näher beschrieben. Diese Module sind jedes für sich und aus anderen Bereich außerhalb des SOA-Umfelds bereits aus dem Stand der Technik bekannt. Zur Realisierung des erfindungsgemäßen TSBI werden die an sich bekannten Module jedoch in einer besonderen Weise eingesetzt und miteinander verschaltet, um im SOA-Umfeld einen Mehrwert gegenüber bekannten SOA-Kapselungen zu realisieren.
Ein Compression Modul 27 komprimiert alle Nachrichten, die den LSBN 22 in Richtung Funknetz verlassen, und dekomprimiert alle Nachrichten, die bei dem LSBN 22 von außerhalb des TSBI 3 eingehen. Ein Encryption Modul 28 verschlüsselt all
Nachrichten, die den LSBN 22 in Richtung Funknetz verlassen, und entschlüsselt alle Nachrichten, die bei dem LSBN 22 von außerhalb des TSBI 3 eingehen. Ein Traffic Shaping Modul 29 überwacht die verfügbare Bandbreite des beschränkten
Netzwerks und sorgt dafür, dass Fehlfunktionen der Sensor Kapselungs Web Services oder fehlerhafte Konfigurationen nicht zu einer abnormalen Anzahl an Nachrichten führen, welche das Netzwerk überfluten. Ein Access Control Modul 30 stellt sicher, dass die SOA einem abgespeckten, aber sicheren Sicherheitsmodell („lightweight but secure security model") entspricht, das für militärische Netzwerke mit geringer
Bandbreite entwickelt wurde.
Ein Radio Adapter 31 ist ein Modul, das die .Nachrichten, welche die LSBN Einheit 22 verlassen, in Datenpakete
umwandelt, die für bestimmte Funkgeräte optimiert sind. Der Radio Adapter 31 berücksichtigt Besonderheiten der
verschiedenen Funkgeräte, bspw. Netzwerk-Protokolle, Größe der Datenpakete, Bandbreite, physikalische Schnittstellen und leitet die Datenpakete weiter an das Funkgerät. Der Radio Adapter 31 fängt außerdem Daten ab, die von dem Funkgerät ankommen und wandelt sie in Nachrichten um, die von dem LSBN 22 verstanden bzw. verarbeitet werden können.
Schließlich verfügt das TSBI 3 über eine
Benutzerschnittstelle 32, die als Administration Interface bezeichnet ist. Über die Schnittstelle 32 kann der VDE 10 bzw. der LSBN 22 konfiguriert werden. Dies erfolgt vorzugsweise anhand einer interaktiv zu bedienenden
grafischen Benutzer-Oberfläche. Der Enterprise Service Bus (ESB) 4 verarbeitet Web Services, die auf dem VDE 10 über das VDE SOA Interface 3.4 verfügbar sind. Der ESB 4 registriert Web Services des VDE 10, indem WSDL-Dateien installiert werden, die von dem Service Registry Modul 21 des VDE 10 angefordert werden. Ein Client Computer 33 verarbeitet Web Services, die auf dem VDE 10 über das VDE SOA Interface 3.4 verfügbar sind. Dabei können Web Service Proxies direkt aus den WSDL-Dateien generiert werden, die von dem Service
Registry Modul 21 des VDE 10 angefordert werden. Mit „Radio" ist ein Funkgerät 34 umfassend einen Sender und/oder
Empfänger bezeichnet. Das nachgeordnete Funknetzwerk ist mit 35 bezeichnet.
Nachfolgend werden die einzelnen Schritte zum Generieren einer Sensor SOA Kapselung („Vendor Device SOA
Encapsulation" ) anhand der Figur 5 näher erläutert. Das
Verbindungsmodul 3 aus Figur 5 entspricht dem in Figur 4 gezeigten. In Figur 5 sind zusätzlich noch einige
Verfahrensschritte durch Zahlen in Kreisen angegeben. Die Verfahrensschritte werden in aufsteigender Reihenfolge und im Wesentlichen an dem Ort abgearbeitet, wo sie eingezeichnet sind .
In einem ersten Schritt 1 (in Figur 5 nicht gezeigt) wird eine Datenübertragungsverbindung zwischen einem
Entwicklungscomputer und dem TSBI 3 hergestellt, vorzugsweise indem das TSBI 3 mittels eines Kabels an den Computer
angeschlossen wird. Ferner wird eine
Datenübertragungsverbindung zwischen dem Entwicklungscomputer und dem einzukapsenden Sensor 2 hergestellt, vorzugsweise indem der Sensor 2 mittels eines Kabels an den Computer angeschlossen wird. Der Sensor 2 kann auch als ein beliebiger Effektor, Aktor oder sonstige Einheit ausgebildet sein, deren Funktionalität in der SOA-Umgebung abgebildet werden soll. Der Entwicklungscomputer kann als ein herkömmlicher Personal Computer (PC), als ein Laptop, ein Palmcomputer und evtl.
sogar als ein Smartphone ausgebildet sein. Der
Entwicklungscomputer ist in Figur 5 durch seinen Benutzer 36 repräsentiert. Vorzugsweise ist der Computer über das
Ethernet an das TSBI 3 angeschlossen. Anschließend werden in einem Schritt 2 (ebenfalls nicht dargestellt) das TSBI 3, der Entwicklungscomputer und der Sensor 2 eingeschaltet, das heißt mit Versorgungsenergie versorgt und hochgefahren
(gebootet), falls erforderlich. Dann wird in einem Schritt 3 (ebenfalls nicht dargestellt) von dem Entwicklungscomputer aus eine Verbindung zu der Verwaltungsstelle des
Administration Interfaces 32 hergestellt.
In einem Schritt 4 wird anschließend über das Administration Interface 32 in dem Vendor Device Encapsulation Generator 19 ein Namensraum für einen bestimmten Service generiert. Dazu muss der Name des Herstellers bzw. Verkäufers des Sensors 2, ein Name des Services und eine Versionsnummer eingegeben werden. Dann werden in einem Schritt 5 ebenfalls über das Administration Interface 32 in dem Vendor Device
Encapsulation Generator 19 ebenfalls die Service Operationen definiert. Dazu werden Funktionen und Benachrichtigungen eingegeben. Anschließend wird in einem Schritt 6 ebenfalls über das Administration Interface 32 in dem Vendor Device Encapsulation Generator 19 das Gerüst des Programmcodes des Projekts heruntergeladen. Dann wird in einem Schritt 7 von dem Benutzer 36 das heruntergeladene Projekt mit einem
Software-Entwicklungswerkzeug geöffnet und die Service-Logik und die Kommunikation mit dem Sensor 2 wird implementiert. Schließlich wird in einem Schritt 8 von dem Benutzer 36 für das Projekt mittels eines Builders eine Binärdatei erzeugt und getestet. In einem Schritt 9 wird dann das Projekt über das
Administration Interface 32 in das TSBI 3 hochgeladen. Die Binärdatei wird in dem Device Encapsulation Container 12 gespeichert. Dann wird in einem Schritt 10 über sog. Remote Logging (Remote Desktop) die erforderliche Software in der Sandbox 11 installiert. Dazu meldet sich der Sensorhersteller von einem entfernten Rechner (dem Entwicklungsrechner 36) auf den virtuellen Rechner (die Sandbox 11) an. Damit kann er extra Software in die Sandbox 11 laden und dort installieren. In einem Schritt 11 wird schließlich der Sensor 2 von dem Entwicklungscomputer gelöst und an das TSBI 3 angeschlossen. Damit ist die Erstellung einer Sensor Kapselung abgeschlossen und die Funktionen des Sensors 2 sind in der SOA-Umgebung abgebildet .
Nachfolgend werden die einzelnen Schritte einer Kommunikation zwischen dem Client Computer 33 aus der SOA-Umgebung und dem Sensor 2 über die Sensor SOA Kapselung („Request Response") anhand der Figur 6 näher erläutert. Das Verbindungsmodul 3 aus Figur 6 entspricht dem in Figur 4 gezeigten. In Figur 6 sind zusätzlich noch einige Verfahrensschritte durch Zahlen in Kreisen angegeben. Die Verfahrensschritte werden in aufsteigender Reihenfolge und im Wesentlichen an dem Ort abgearbeitet, wo sie eingezeichnet sind. Die
Verfahrensschritte aus Figur 6 sind unabhängig von den
Schritten der Figur 5 und haben mit diesen nichts zu tun, obwohl die einzelnen Schritte zum Teil die gleichen Nummern haben .
In einem ersten Schritt 1 der Figur 6 kommt eine Anfrage- Nachricht im SOAP (Simple Object Access Protocol ) -Format von dem Client Computer 33 über die physikalische Schnittstelle 3.4 zu dem Request-Response Messaging Provider 17 des TSBI 3. Die Nachricht wird in einem Schritt 2 über den Bus 16 übertragen und gelangt in einem Schritt 3 schließlich in den Vendor Device SOA Encapsulation Container 12. Dann wird in einem Schritt 4 eine Funktion aufgerufen, welche die dem durch die SOAP-Nachricht angesprochenen Service entsprechende Sensorfunktion mittels Reflektion (ermöglicht es bei
objektorientierter Programmierung, Informationen über Klassen oder deren Instanzen abzufragen) ermittelt. In einem Schritt 5 interagiert die Sensor SOA Kapselung 12 mit dem Sensor 2. Der Ausgang bzw. die Antwort des Sensors 2 wird in einem Schritt 6 in eine SOAP-Nachricht konvertiert. Die Antwort- Nachricht im SOAP-Format wird in einem Schritt 7 über den Bus 16 an den Request-Response Messaging Provider 17 übertragen. Schließlich verlässt in einem Schritt 8 die SOAP Antwort- Nachricht den Request-Response Messaging Provider 17 und wird zurück an den Client 33 gesandt.
Wenn sich ein Client Computer 33 bei dem TSBI 3 anmelden möchte, sendet er eine Anmeldenachricht an den Publish/
Subscribe Messaging Provider 18 und wird dort als Abonnent vermerkt. Jede Notifikation besteht aus einem Topic (Thema; Betreff) und einem Body (Körper; Inhalt) . Der Topic ist ein Identifikationsparameter; der Body ist eine
Inhaltsbeschreibung der Nachricht, die beim Notifizieren herausgeschickt wird. Beim Publish-Subscribe Message Exchange Pattern muss der Nutzer (Consumer; Client 33) dem Provider (TSBI 3) mitteilen, für welche Notifikationen er sich
interessiert (Mitteilung der Topics). Wenn beim Provider eine Notifikation getriggert wird, schickt er diese an alle
Nutzer, die sich für dieses Topic abonniert haben.
Nachfolgend werden die einzelnen Schritte anhand der Figur 7 näher erläutert, die ausgeführt werden, wenn Teilnehmer in der SOA-Umgebung über Ereignisse im Sensor 2 informiert werden („Publish") . Das Verbindungsmodul 3 aus Figur 7 entspricht dem in Figur 4 gezeigten. In Figur 7 sind
zusätzlich noch einige Verfahrensschritte durch Zahlen in Kreisen angegeben. Die Verfahrensschritte werden in
aufsteigender Reihenfolge und im Wesentlichen an dem Ort abgearbeitet, wo sie eingezeichnet sind. Die
Verfahrensschritte aus Figur 7 sind unabhängig von den
Schritten den Figuren 5 und 6 und haben mit diesen nichts zu tun, obwohl die einzelnen Schritte zum Teil die gleichen Nummern haben.
In einem ersten Schritt 1 der Figur 7 tritt ein bestimmtes Ereignis in dem Sensor 2 ein (z.B. ein Radar erkennt ein Objekt und liefert ein sog. Track; ein Bewegungssensor meldet kleine Änderungen der Beschleunigung o.ä.) . Die Sensor
Kapselung 12 wird darüber in einem Schritt 2 informiert und ruft die zugeordnete Benachrichtigungsfunktion auf. Der
Ausgang bzw. die Ausgabe der Benachrichtigungsfunktion wird in einem Schritt 3 in eine SOA-Nachricht konvertiert. Die Nachricht wird in einem Schritt 4 über den Bus 16 an den Pub/Sub Messaging Provider 18 übertragen. Durch den Pub/Sub Messaging Provider 18 wird die SOA-Nachricht dann in einem Schritt 5 an alle in dem SOA-Umfeld bei dem TSBI 3 als
Abonnenten registrierten Client Computer 33 übertragen.
Nachfolgend werden ohne Bezugnahme auf eine besondere Figur die verschiedenen Verfahrensschritte erläutert, die
erforderlich sind, um einen Web Service Client mit Hilfe eines Computers (in den Figuren 4-8 repräsentiert durch den Benutzer 36) zu entwickeln. In einem ersten Schritt 1 wird eine Datenverbindung zwischen dem Computer 36 und dem TSBI 3 hergestellt, bspw. indem der Computer 36 mittels eines Kabels an das TSBI 3 angeschlossen wird. In einem nachfolgenden Schritt 2 wird eine geeignete WSDL (Web Services Description Language) von der Service Registry 21 des TSBI 3 angefordert und auf den Computer 36 heruntergeladen. Dann wird in einem Schritt 3 aus der WSDL der Quellcode für den Service Proxy generiert. Schließlich wird in einem Schritt 4 der Proxy in das auf dem Computer 36 ablaufende Software- Entwicklungswerkzeug importiert und der Web Service Client entwickelt . Nachfolgend werden ohne Bezugnahme auf eine besondere Figur die verschiedenen Verfahrensschritte erläutert, die
erforderlich sind, um eine Integration in einem Enterprise Service Bus (ESB) 4 zu erreichen. In einem ersten Schritt 1 wird eine Datenverbindung zwischen dem TSBI 3 und einem
Teilnehmer des Service Bus (Service Bus Node) hergestellt, bspw. indem der TSBI 3 mittels eines Kabels an das System, das den ESB Stub 4 hostet, angeschlossen wird oder beim
Installieren des ESB Stub 4 auf dem TSBI 3. In einem
nachfolgenden Schritt 2 wird eine geeignete WSDL (Web
Services Description Language) von der Service Registry 21 des TSBI 3 angefordert und in der Service Registry des ESB 16 installiert .
Schließlich wird unter Bezugnahme auf die Figur 8 die Nutzung der Services in der SOA-Umgebung über ein bandbreitenmäßig beschränktes militärisch genutztes Netzwerk, wie bspw. das Funknetzwerk 35, näher erläutert („Service Consumption
(Request/ Response) over a contrained tactical network"). Die Datenübertragung über das Funknetzwerk 35 kann dabei nach einem beliebigen Protokoll oder Standard erfolgen.
Entscheidend ist, dass die Bandbreite des Funknetzes 35 deutlich unterhalb der Bandbreite ziviler Kommunikationsnetze (Gigabit-LAN) liegt, bspw. im Bereich von lediglich einigen Bytes/sec oder sogar im Bereich von nur einigen kBytes/sec, insbesondere im Bereich von etwa 4 bis 20 kBytes/sec und in Ausnahmefällen in einem Bereich bis max. 60 kBytes/sec.
Figur 8 zeigt zwei TSBIs, nämlich TSBI A (Bezugszeichen 3) und TSBI B (Bezugszeichen 3' ) . Grundsätzlich sind in Figur 8 alle Elemente des ersten TSBI A wie in den vorangegangenen Figuren 4-7 bezeichnet und die Elemente des weiteren TSBI B dementsprechend mit versehen. Die Verbindungsmodule 3, 3' aus Figur 8 entsprechen jeweils dem in Figur 4 gezeigten. Der LSBN 22 des TSBI A 3 ist bspw. für Services a bis c zuständig, während der LSBN 22' des anderen TSBI B 3' für Services d bis f zuständig ist. Die LSBNs 22, 22' der TSBIs 3, 3' des dargestellten Netzwerks synchronisieren sich aufeinander, damit der eine TSBI auch auf die Services des anderen TSBI zugreifen und diese konsumieren kann. Um
Bandbreite zu sparen, findet die Synchronisation nicht in regelmäßigen zeitlichen Abständen statt. Vielmehr erfolgt die Synchronisation, insbesondere zur Integration neuer TSBIs in das Netzwerk, entweder auf ausdrücklichen Befehl eines
Anwenders (d.h. Knopfdruck und Eingabe eines Sicherheitscodes o.ä.) oder während einer sog. Mission Preparation vor der Laufzeit des Netzwerks.
Im Rahmen der Synchronisation der TSBIs 3, 3' werden die in den verteilten TSBIs 3, 3' jeweils verwalteten Services in den Service Discovery Modulen 25, 25' aller TSBIs 3, 3' abgespeichert, so dass jeder LSBN 22, 22' sowohl die von dem VDE 10, 10' des eigenen TSBI 3, 3' verwalteten Services als auch alle von den VDEs 10, 10' der anderen TSBIs 3, 3' des Netzwerks kennt. So sind bspw. in der Service Discovery 25' des TSBI B 3' sowohl Informationen über die Services d bis f des TSBI B 3' also auch Informationen über die Services a bis c des anderen TSBI A 3 des Netzwerks abgespeichert.
In Figur 8 sind zusätzlich noch einige Verfahrensschritte durch Zahlen in Kreisen angegeben. Die Verfahrensschritte werden in aufsteigender Reihenfolge und im Wesentlichen an dem Ort abgearbeitet, wo sie eingezeichnet sind. Die
Verfahrensschritte aus Figur 8 sind unabhängig von den
Schritten aus den Figuren 5 bis 7 und haben mit diesen nichts zu tun, obwohl die einzelnen Schritte zum Teil die gleichen Nummern haben.
In einem ersten Schritt 1 sendet ein Client Computer 33 des TSBI A eine SOAP Anfrage-Nachricht an den Request /Response Messaging Provider 17 des TSBI A. In einem nachfolgenden Schritt 2 erkennt der TSBI A, dass der angeforderte Service nicht auf ihm selbst lokalisiert ist, sondern auf einem anderen TSBI B, das heißt der angeforderte Service wird nicht durch TSBI A, sondern durch TSBI B zur Verfügung gestellt. Der TSBI B ist dem Netzwerk und insbesondere dem TSBI A bekannt, da der TSBI B in dem Distributed Service Registry 26 des LSBN 22 aufgelistet ist. In einem Schritt 3 wird die SOAP-Nachricht komprimiert (Einheit 27) und verschlüsselt (Einheit 28) und an den Funkadapter 31 übermittelt, der die Nachricht in einem Schritt 4 an das Funkgerät 34
weiterleitet .
In einem Schritt 5 wird die Nachricht von dem Funkgerät 34 des TSBI A über das Funknetz 35 an das Funkgerät 34' des TSBI B übertragen. In einem Schritt 6 geht die Nachricht in dem Funkadapter 31' des TSBI B ein. Dann wird die Nachricht in einem Schritt 7 entschlüsselt und extrahiert und an den
Request/Response Messaging Provider 17' des TSBI B
übertragen. Danach wird die Nachricht in einem Schritt 8 über den Bus 16' übertragen und kommt in der Kapselung des Sensors 2' („Vendor Device SOA Encapsulation" ) 12' an. In einem
Schritt 10 wird mittels Reflektion die passende
Servicefunktion aufgerufen. In einem Schritt 11 interagiert die Kapselung 12' des Sensors 2' mit dem Sensor 2' . Dann wird in einem Schritt 12 der Ausgang bzw. die Ausgabe der
Servicefunktion in eine SOAP Antwort Nachricht umgewandelt. In einem Schritt 13 wird die SOAP Nachricht über den Bus 16' und den Request/Response Messaging Provider 17' des VDE 10' an den LSBN 22' übertragen, wo die SOAP Nachricht in einem Schritt 14 komprimiert, verschlüsselt und an den Funkadapter 31' übermittelt wird. In einem Schritt 15 leitet der
Funkadapter 31' die SOAP Nachricht weiter an das Funkgerät 34' des TSBI B. Die SOAP Nachricht wird in einem Schritt 16 über das Funknetz 35 an das Funkgerät 34 des TSBI A
übermittelt. In einem Schritt 17 kommt die SOAP Nachricht in dem Funkadapter 31 des TSBI A an. In dem LSBN 22 des TSBI A wird die empfangene SOAP Nachricht dann in einem Schritt 18 dekomprimiert und entschlüsselt und zu dem Request/ Response Messaging Provider 17 des VDE 10 gesandt. Die SOAP Antwort Nachricht verlässt den Request/ Response Messaging Provider 17 und wird zurück zu dem Client 33 gesandt.
In Figur 9 ist ein bevorzugtes Ausführungsbeispiel für ein erfindungsgemäßes TSBI 3 dargestellt. Es umfasst ein Gehäuse 40 zur Aufnahme der elektrischen Komponenten und Bauteile. Das Gehäuse 40 weist nach oben gerichtet eine Öffnung auf, die mittels eines Deckels 41 verschlossen ist. Der Deckel 41 ist lösbar, bspw. mittels Schrauben 42, auf dem Gehäuse 40 befestigt. Das Gehäuse 40 und der Deckel 41 sind vorzugsweise aus Metall, insbesondere aus Aluminiumdruckguss , gefertigt. An der Vorderseite des Gehäuses 40 sind verschiedene
Steckerelemente ausgebildet. Insbesondere sind ein erster Ethernet-Anschluss 43, ein zweiter Ethernet-Anschluss 44, zwei USB-Ports 45, ein RS232-Anschluss 46, ein Audio- und/oder Video-Anschluss 47, ein Anschluss 48 für VGA und einen CAN-Bus sowie ein Energieversorgungsanschluss 49 vorgesehen. Es liegt eine Versorgungsspannung von 12 Volt an dem TSBI 3 an. Zum Hochfahren unmittelbar nach dem Start des TSBI 3 benötigt dieses etwa 5 Ampere Stromstärke, danach nur noch etwa 1 Ampere. Mit dem Bezugszeichen 50 ist ein Ein-/ Ausschalter bezeichnet.
An die Anschlüsse 43 bis 49 werden Kabel mit passenden
Steckern angeschlossen, die an ihrem anderen Ende die
üblichen Steckerelemente (Stecker oder Buchsen) für das entsprechende Format haben, bspw. einen üblichen Ethernet- Stecker für die Anschlüsse 43 und 44, zwei herkömmliche USB- Stecker für die Anschlüsse 45, ein RS232-Stecker für den RS232-Anschluss 46, Audio- und Video-Buchsen für den
Anschluss 47, und einen VGA-Stecker sowie einen CAN-Bus- Stecker für den Anschluss 48. Während des Kapseins eines neuen Sensors 2 oder zum Verwalten des TSBI 3 kann an den Anschluss 43 oder 44 ein
Entwicklungsrechner zum Generieren einer Kapselung des
Sensors 2 („vendor device SOA encapsulation" ) , wie sie oben unter Bezugnahme auf Figur 5 beschrieben ist, angeschlossen werden. Während des Kapseins eines neuen Sensors 2 oder während des bestimmungsgemäßen Betriebs des TSBI 3 kann ein Sensor 2 in Form einer Kamera an den Anschluss 47
angeschlossen sein, so dass Audio- und/oder Videosignale von dem Sensor 2 an das TSBI 3 übermittelt werden können. Die Energieversorgung wird an den Anschluss 49 angeschlossen.
Zusammenfassend kann festgehalten werden, dass es sich bei dem TSBI 3 um ein sog. Konvergenzmodul handelt, das beliebige Firmware der Sensoren 2 in einen SOA-kompatiblen Standard umsetzen kann. Das TSBI 3 umfasst sowohl Hardware- als auch Softwarekomponenten. Ziel des TSBI 3 ist es, einfache und komplexe Funktionalitäten als Services gemäß WebService- Standards bereitzustellen. Die Hauptanforderung für die
Entwicklung des VDE 10 ist die für jedermann einfach,
generisch und sicher durchführbare Kapselung von Geräten und Systemen („any vendor' s device"), z.B. eines Sensors 2.
Dadurch ist das VDE 10 in der Lage, legacy Systeme, die von sich aus keine WebService-Schnittstelle anbieten, in eine moderne Service orientierte Architektur zu integrieren. Diese Kapselung kann vom Hersteller (Vendor) des zu kapselnden Geräts 2 selbst vorgenommen werden. Die Automatismen und Werkzeuge des VDE 10 unterstützen den Hersteller dabei. Die VDE-Infrastruktur 10 adaptiert die SOA-Mechanismen derart auf bestehende Programmiersprachen, dass der Hersteller kein Wissen über Webserviceschnittstellen (WSDL) für die Kapselung benötigt .
Mit der vorliegenden Erfindung ist also eine Kapselung von beliebigen Geräten 2 ohne Know-How über Webservices möglich. Für die Kapselung der Funktionen eines Gerätes (z.B. Drehen, Zoomen, etc.) zu seinen Diensten (Services) benötigt der Hersteller kein Wissen über Webserviceschnittstellen. Das VDE 10 generiert intern die zum Bus 4/ Client 33 passende WSDL und zum Gerät 2 passende Schnittstelle. Der Hersteller bekommt außerdem ein C++ Template, in dem er seine
hardwarespezifischen Anpassungen vornehmen kann. Bei einer Kapselung mit dem TSBI muss der Sensorhersteller (Vendor) seine Schnittstelle nicht offenlegen, wodurch die Akzeptanz der Erfindung durch die Hersteller deutlich verbessert werden kann .
Die sog. Reflektionen mit C++ („pointer to Operation") ermöglichen es, bei objektorientierter Programmierung bspw. Informationen über Klassen oder deren Instanzen abzufragen. Dies kann unter anderem deren Sichtbarkeit, der Datentyp des Rückgabewertes oder der Typ der Übergabeparameter sein. Die Umsetzung der Abfragemöglichkeiten ist sprachspezifisch. In C++ muss zur Laufzeit zum richtigen Zeitpunkt die zugehörige Speicheraddress ausfindig gemacht werden, damit die Funktion aufgerufen werden kann. Lesbarer C++ Code wird nach der
Kompilierung in reine Speicheradressen gewandelt.
Um die Herstellerinformationen und die Dienste in
verschiedenen Versionen verwalten zu können (vgl. Figur 5, Schritt 4), besitzt der VDE 10 ein Repository, in dem alle Servicebeschreibungen abgelegt werden. Eine
Abwärtskompatibilität durch Versionierung bei Verwendung neuer Softwareversionen muss sichergestellt sein.
Jedes VDE 10 bringt sein eigenes Repository mit. Es gibt also keinen zentralen Knoten als „Achillesferse", auf dem die Daten liegen und der ausfallen könnte. Durch die dezentrale, verteilte Architektur ist ein TSBI-Netz nur schwer zu
zerschlagen. Ein erstes TSBI A kann auf die Funktionalität eines zweiten TSBI B über ein Funknetz 35 zugreifen (vgl. Figur 8) . Die Geräte 2, die vom VDE gekapselt werden, müssen zur
Ausführung einer Aktion getriggert werden bzw. sie müssen ihren letzten Status wissen. Webservices, die - wenn sie einmal ausgeführt sind - gelöscht werden bzw. ihren Status wieder vergessen, sind somit nicht für eine direkte
Kommunikation mit Legacy Geräten geeignet. Webserviceaufrufe liegen in der Regel simultan d.h. in großer Anzahl vor. Ein Gerät verarbeitet Aufrufe aber sequentiell. Dadurch würde ein erneuter Aufruf während der Abarbeitung eines bereits
angenommenen Aufrufes verloren gehen. Der VDE 10 löst dieses Problem, indem er die über das Request/Response Modul 17 eingehenden Service Aufrufe zwischenspeichert zumindest bis sie abgearbeitet werden können. Das Modul 17 sorgt auch für die Abarbeitung der eingehenden Aufrufe in der richtigen Reihenfolge. Wenn den eingehenden Service Aufrufen
Prioritäten zugeordnet sind, kann das Modul 17 diese
ebenfalls bei der Festlegung der Reihenfolge der Abarbeitung berücksichtigen .
Fehler, die im VDE 10 entstehen, werden als „SOAP-Fehler" (Fehlermeldung) vom VDE 10 ausgegeben. Dies gilt vor allem für die Softwarekomponenten, die von den Herstellern in den VDE 10 importiert werden. Auf diese Weise ist sichergestellt, dass ein Fehler erkannt wird, damit sofort entsprechend gegengesteuert werden kann. Das heißt also, dass Fehler des gekapselten Geräts 2 als SOAP-Fehler in Erscheinung treten und erkannt werden können. Die Sandbox 11 isoliert die Geräte 2 im VDE 10 vollständig. Dies erhöht die Sicherheit und gleichzeitig die Verfügbarkeit, da die isolierten Geräte 2 nur schwer angreifbar sind. Weiter wird mittels des Watchdog Timers 15 sichergestellt, dass die Geräte 2 sowie die Sandbox 11 selbst verfügbar sind. Dazu sendet die Kapselung eines Gerät 2 zu vorgegebenen Zeitpunkten, vorzugsweise regelmäßig, eine Heartbeat-Nachricht an den Watchdog 15. Falls es zu einem Systemabsturz kommt, wird die Sandbox 11 automatisch neu gestartet. Ein „Einfrieren" des Systems ist somit
ausgeschlossen. Mit dem VDE 10 kann sich der Benutzer 36 leicht mit unterschiedlichen Servicebussen 4 verbinden. Der VDE 10 arbeitet problemlos mit allen marktüblichen
Servicebussen 4 zusammen. Der TSBI 3 lernt dabei auf
Knopfdruck um welchen Servicebus 4 es sich handelt. So lassen sich die Geräte 2 leicht an unterschiedliche Domänen koppeln. Die adaptive Servicebus Schnittstelle stellt
Interoperabilität auf höchstem Niveau sicher.
Die von dem Verbindungsmodul 3 generierten und einer oder mehreren Funktionen des gekapselten Geräts 2 entsprechenden Services können von beliebigen anderen Knoten (sog. Nodes) des SOA-Netzwerks angesprochen werden. Damit ein Knoten einen Service aufrufen und konsumieren kann, ist es - anders als im Stand der Technik, bspw. der US 2007/0236346 AI, nicht erforderlich, dass Software von dem Verbindungsmodul 3 an den aufrufenden Knoten übermittelt, dort abgespeichert und ausgeführt wird. Das Aufrufen der Services und die
Kommunikation der Knoten der SOA-Umgebung mit dem
Verbindungsmodul 3 erfolgt lediglich über die Web-Service- Schnittstelle 17 (Request /Response ) sowie über die Pub/SubSchnittstelle 18 (Subscribe/Publish) . In der US 2007/0236346 AI wird Service Firmware von einem Knoten auf andere Knoten übertragen, damit diese miteinander kommunizieren können.
Das schließt jedoch nicht aus, dass bei dem erfindungsgemäßen Verbindungsmodul 3 eine von dem VDE 10 generierte Exportdatei auf andere Verbindungsmodule 3 bzw. andere VDEs 10 übertragen werden kann, um dort die gleichen Geräte 2 zu kapseln. Es ist also möglich, die für ein Gerät 2 erstellte Kapselung auf andere VDEs 10 zu übertragen, so dass Geräte vom gleichen Typ des Geräts 2 dort mit minimalem Aufwand gekapselt werden können . In einem Ausführungsbeispiel, in dem der TSBI 3 mit einem ESB 4 in Verbindung steht, überträgt die Firmware des TSBI 3 den Service nicht automatisch an das Netzwerk. Vielmehr müssen die Service Beschreibungen in der Service Registry des ESB 4 installiert werden. Der ESB 4 weiß, dass ein bestimmter
Service verfügbar ist, indem er die Heartbeat-Notifikationen des Services empfängt. Der Service selbst wird - anders als bspw. in der US 2007/0236346 AI - nie zwischen den Knoten übertragen, vielmehr wird er aus der Ferne (remotely) mittels SOAP konsumiert.
Falls das TSBI 3 in einem militärischen Umfeld eingesetzt wird, kann es den LSBN 22 einsetzen. Anders als in der US 2007/0236346 AI gibt es keine zentrale Plattform oder
Einheit, welche den Anschluss neuer Geräte beobachtet bzw. kontrolliert. Der LSB ist ein vollständig verteilter Service Bus für den militärischen Einsatz, der sich auf die anderen Knoten (Nodes) synchronisiert. Weder Treiber noch Services werden von einem TSBI 3 zu einem anderen TSBI 3' über den LSB übertragen. Der LSBN 22 installiert lediglich Service
Abbildungen (Representations ) , bspw. im WSDL, auf Anfrage und Services werden über entfernte (remote) Prozeduraufrufe
(SOAP) konsumiert.
Anhand der Figur 10 soll die vorliegende Erfindung noch detaillierter erläutert werden. Die Figur 10 zeigt ein TSBI 3, ein zu kapselndes, an sich nicht-SOA-fähiges Gerät 2, sowie einen Client 36, der aus der SOA-Umgebung heraus auf das Gerät 2 zugreifen möchte. Das Gerät 2 ist bspw. eine bewegbare Kamera oder ein bewegbares Waffensystem. Eine erste Funktion Fktl des Geräts 2 entspricht bspw. einem Schwenken und eine zweite Funktion Fkt2 einem Neigen der Kamera bzw. der Waffe. Bei einer Kamera könnte eine dritte Funktion Fkt3 bspw. eine Funktion zum Bestätigen der erfolgten Schwenkbzw. Neigebewegung sein. Bei einer Waffe könnte die dritte Funktion Fkt3 bspw. eine Funktion zum Abfeuern der Waffe sein .
Selbstverständlich kann das Gerät 2 auch mehr oder weniger oder andere als die dargestellten drei Funktionen Fktl bis Fkt3 aufweisen. Diese Funktionen sind durch mindestens eine physikalische Schnittstelle 60 aufrufbar und können über ein vom Hersteller geliefertes API (Application Programming
Interface) , ein vom Hersteller geliefertes Softwaremodul oder ein vom Hersteller definiertes Protokoll aufgerufen werden. Aufbau und Funktionsweise der gerätespezifischen
Softwareschnittstellen sind ausschließlich dem Hersteller des Geräts 2 bekannt. Die einzelnen Funktionen Fktl bis Fkt3 sind durch Programmcode realisiert, der auf einem Rechengerät, bspw. einem Prozessor, des Geräts 2 abläuft. Der Programnacode ist in Figur 10 durch abzuarbeitende Befehle cl, c2, c3, ... veranschaulicht und in seiner Gesamtheit mit dem
Bezugszeichen 61 bezeichnet. Der Programmcode 61 ist in der Regel proprietär, häufig in der Programmiersprache C++ programmiert und nur dem Hersteller des Geräts 2 bekannt.
Während des herkömmlichen, nicht-SOA-fähigen ungekapselten Betriebs des Geräts 2 wird das Gerät 2 über die Schnittstelle 60 mit Befehlen, bspw. von einem Computer oder einem Joystick aus, angesteuert. Dabei werden Aufrufe, möglicherweise mit bestimmten Übergabeparametern, an die Schnittstelle 60 der auszuführenden Funktion Fktl bis Fkt3 gesandt. Ein Aufruf könnte bspw. heißen: „Schwenken um 45°", wobei in diesem Fall die erste Funktion Fktl aufgerufen wird und 45° einen
Übergabeparameter für die Funktion Fktl darstellt. Je nach auszuführender Funktion gibt diese ein Ergebnis zurück oder auch nicht. Die Funktion Fktl kann bspw. ein Ergebnis
zurückgeben, um ein erfolgreiches Schwenken des Geräts 2 zu vermelden. Alternativ wäre es auch denkbar, dass eine
separate Funktion, bspw. die Funktion Fkt3, vorgesehen ist, um ein erfolgreiches Schwenken und/oder Neigen des Geräts 2 zu vermelden. Die Funktion Fkt3 wird nach der Funktion Fktl aufgerufen, bspw. ohne einen Übergabeparameter. Als
Rückgabeparameter kann die Funktion Fkt3 einen Boolean-Wert („1" oder „0") zurückgeben, um ein erfolgreiches bzw.
erfolgtes Schwenken bzw. Neigen des Geräts 2 zu
signalisieren .
Das TSBI 3 umfasst eine Rahmenstruktur 62, die anhand von Vorgaben des Herstellers des Geräts 2 automatisch generiert wird. Der Hersteller gibt bspw. an, welche Funktion (en) der Funktionen Fktl bis Fkt3 des Geräts 2 er kapseln möchte und ob und wenn ja welche Parameter (Eingangsgrößen,
Ausgangsgrößen) die zu kapselnden Funktionen erwarten bzw. zurückgeben. Wenn in dem Beispiel der Figur 10 die erste Funktion Fktl gekapselt werden soll, gibt der Hersteller des Geräts 2 die Funktion „Schwenken" vor, als Eingangsparameter eine Winkelgröße (z.B. vom Typ Integer) für eine Bewegung des Geräts 2 und als Ausgangsparameter eine j a/nein-Aussage (z.B. vom Typ Boolean) als Information darüber, ob das Schwenken erfolgreich war, d.h. ob der gewünschte Endpunkt erreicht worden ist. Entsprechende Parameter kann der Hersteller für die Funktion Fkt2 „Neigen" vorgeben. Für die Funktion Fkt3 kann der Hersteller bei einer Kamera bspw. als zu kapselnde Funktion „Bewegung prüfen" vorgeben, keine Eingangsparameter und als Ausgangsparameter eine ja/ nein-Aussage (z.B. vom Typ Boolean), ob das Schwenken/ Neigen erfolgreich war.
Anhand der vom Hersteller des Geräts 2 vorgegebenen
Funktionen und Parameter wird automatisch die Rahmenstruktur 62 des TSBI 3 generiert. Das Administration Interface 32 (vgl. Figuren 4 bis 8) des TSBI 3 dient zum Definieren des Gerüsts bzw. der Rahmenstruktur 62. Generiert wird die
Rahmenstruktur 62 dann durch den Vendor Device Encapsulation Generator 19 im VDE 10. Die Rahmenstruktur 62 umfasst auch vom Hersteller definierte Eingänge 63 bzw. Ausgänge 64 für die Eingangs- bzw. Ausgangsparameter der gekapselten Funktionen Fktl bis Fkt3. Die Eingänge 63 bzw. Ausgänge 64 können bspw. durch ein sog. Admin-GUI (Graphical User
Interface) realisiert sein.
Um die Kapselung einer der Funktionen Fktl bis Fkt3 des
Geräts 2 zu realisieren, muss an einer vorgegebenen Stelle der Rahmenstruktur 62 der Programmcode 61 der entsprechenden Funktion in der Rahmenstruktur 62 abgelegt bzw. in diese eingebunden werden. Für die Funktion Fkt2 ist bspw. in der Rahmenstruktur 62 der Programmcode 61' (cl, ...) der zweiten Funktion Fkt2 des Geräts 2 abgelegt. Der in der
Rahmenstruktur 62 abgelegte Programmcode 61' entspricht dem Vendor-Custom-Software-Block 13 in der Sandbox 11 des TSBI aus den Figuren 4 bis 8. Dadurch ist das Know-How des
Herstellers in Form des Programmcodes 61 des Geräts 2 vor unbefugten Zugriffen durch Dritte geschützt.
Statt des tatsächlichen Programmcodes 61' kann der Hersteller des Geräts 2 an der vorgegebenen Stelle der Rahmenstruktur 62 auch einfach Verweise auf den Programmcode 61 in dem Gerät 2 in der Rahmenstruktur 62 ablegen bzw. programmieren. Der Verweis umfasst bspw. einen Aufruf 65 und einen Programmcode zur Entgegennahme eines Ergebnisses 66. Ein solcher Aufruf 65 ist beispielhaft für die Kapselung der ersten Funktion Fktl in der Rahmenstruktur 62 in Figur 10 gezeigt. Ebenso ist für die erste Funktion Fktl der Programmcode zur Entgegennahme eines Ergebnis 66 programmiert. Der Aufruf des Programmcodes 61 der ersten Funktion Fktl des Geräts 2 ist durch einen mit durchgezogener Linie gezeichneten Pfeil von dem TSBI 3 zu der Schnittstelle 60 der ersten Funktion Fktl des Geräts 2 veranschaulicht. Ebenso ist die Rückgabe des Ergebnisses der Funktion Fktl durch einen mit durchgezogener Linie
gezeichneten Pfeil von der Schnittstelle 60 der ersten
Funktion Fktl des Geräts 2 zu dem TSBI 3 veranschaulicht. Falls die Funktion Fktl des Geräts 2 dergestalt ist, dass sie kein Ergebnis zurückgibt, kann der Programmcode 66 an der Stelle der Funktion Fktl in der Rahmenstruktur 62 auch entfallen. Statt dessen könnte bsp . nach dem Aufruf 65 der ersten Funktion Fktl des Geräts 2 eine andere Funktion des Geräts 2, bspw. die Funktion Fkt3, aufgerufen werden, um zu prüfen, ob die durch Abarbeiten des Programmcodes 61 der ersten Funktion Fktl ausgeführte Schwenkbewegung des Geräts 2 erfolgreich abgeschlossen wurde. Die Funktion Fkt3 liefert als Ergebnis eine Information zurück, ob die angestrebte Ziel der Schwenkbewegung erreicht worden ist (z.B. einen Boolean- Wert) . Der Aufruf der dritten Funktion Fkt3 ist in Figur 10 durch einen mit gestrichelter Linie gezeichneten Pfeil von dem TSBI 3 zu dem API 60 der dritten Funktion Fkt3 des Geräts 2 veranschaulicht. Ebenso ist die Rückgabe des Ergebnisses der Funktion Fkt3 durch einen mit gestrichelter Linie
gezeichneten Pfeil von der Schnittstelle 60 der dritten
Funktion Fkt3 des Geräts 2 zu dem TSBI 3 veranschaulicht.
Schließlich wäre es auch denkbar, dass durch das TSBI 3 nicht nur Funktionen Fktl bis Fkt3 des Geräts 2, sondern auch andere Funktionen, die bspw. lediglich auf einem außerhalb des Geräts angeordneten separaten Rechner 67, insbesondere einem Computer, ablaufen, durch das TSBI 3 in einem SOA- Umfeld abgebildet werden. Dabei ist es denkbar, dass
Programmcode von dem Rechner 67 entweder direkt in die
Rahmenstruktur 62 kopiert bzw. dort programmiert wird (Vendor Custom Software 13) oder lediglich Verweise auf den
Programmcode des Rechners 67 in der Rahmenstruktur 62
abgelegt sind. Es ist denkbar, dass der Rechner 67 über eine (nicht dargestellte) Datenübertragungsverbindung mit dem Gerät 2 in Verbindung steht, so dass eine Abarbeitung des Programmcodes auf dem Rechner 67 eine entsprechende Aktion oder Funktion des Geräts 2 auslösen bzw. Rückgabewerte von dem Gerät 2 verarbeiten kann. Auf diese Weise ist es auch möglich, nicht nur einzelne Funktionen des Geräts 2 oder externer Rechner 67, sondern auch komplexe Systeme zur
Realisierung mehrerer Funktionen zu kapseln.
Nach der erfolgten Kapselung der Funktionen Fktl bis Fkt3 des Geräts 2, kann ein Client 36 aus der SOA-Umgebung mittels SOA-Aufrufe (z.B. Request) auf die gekapselten Funktionen Fktl bis Fkt3 zugreifen bzw. Rückmeldungen der Funktionen (z.B. Response) im SOA-Umfeld empfangen und verarbeiten. In Figur 10 ist bspw. eine Request 68 des Client 36 an die gekapselte erste Funktion Fktl dargestellt. Die Request 68 kann einen oder mehrere Übergabeparameter umfassen, im Fall der Funktion „Schwenken" bspw. eine Winkelangabe für die Schwenkbewegung. Ebenso ist eine Response 69 von der
gekapselten ersten Funktion Fktl zu dem Client 36
dargestellt. Auch die Response 69 kann einen oder mehrere Rückgabeparameter umfassen, im Fall der Funktion „Schwenken" bspw. eine Information, ob die Schwenkbewegung erfolgreich war. Wenn keine Parameter übergaben werden, wird das
entsprechende Feld des SOA-Aufrufs 68, 69 einfach leer gelassen .
Das TSBI 3 „übersetzt" den SOA-Aufruf in ein für das Gerät 2 bzw. den dort abgelegten Programmcode verständliches bzw. kompatibles Format. Dies geschieht durch die vom Hersteller des TSBI 3 vorgegebenen Algorithmen. Der Hersteller des
Geräts 2, der die gerätespezifische Programmierung des TSBI 3 vornimmt, muss keinerlei Kenntnisse über Webservices und die SOA-Welt haben. Außerdem wird die Abarbeitung mehrerer SOA- Aufrufe 68 im TSBI 3 bzw. in dem Gerät 2 durch den TSBI 3 koordiniert. Insbesondere können den SOA-Aufrufen 68 evtl. zugeordnete Prioritäten der Aufrufe 68 in die proprietäre gerätespezifische Umgebung übersetzt und dort berücksichtigt werden. Die Berücksichtigung von Prioritäten ist wichtig, da sonst am Beispiel eines als Kamera ausgebildeten Geräts 2 die dritte Funktion Fkt3 ein falsches Ergebnis bezüglich des Erfolgs der Schwenk- oder Neigebewegung liefert, wenn nicht zunächst die erste oder die zweite Funktion Fktl oder Fkt2 vollständig abgearbeitet wird. Am Beispiel eines als Waffe ausgebildeten Geräts 2 würde die dritte Funktion zu einem Auslösen der Waffe führen, obwohl die Endposition der Schwenk- oder Neigebewegung noch nicht erreicht ist.

Claims

Patentansprüche
1. Verbindungsmodul (3) zum Anbinden mindestens eines
Geräts (2) an ein Service Oriented Architecture- , genannt SOA-, Netzwerk (4), wobei eine Funktionalität des mindestens einen Geräts (2) als ein Dienst im SOA- Netzwerk (4) abgebildet ist, das Verbindungsmodul (3) mindestens eine erste Schnittstelle (3.2) zum Anschluss des mindestens einen Geräts (2) und mindestens eine zweite Schnittstelle (3.4) zum Anschluss des SOA- Netzwerks (4) aufweist, und das Verbindungsmodul (3) ein Rechengerät (7) zum Abarbeiten eines Computerprogramms aufweist, wobei ein Teil (8.1) des abzuarbeitenden
Computerprogramms standardmäßig vorgegeben ist und ein anderer Teil (8.2) des Computerprogramms von einem
Hersteller des mindestens einen Geräts (2) frei
programmierbar ist, um eine Anpassung einer auf dem mindestens einen Gerät (2) vorhanden Firmware an das SOA-Netzwerk (4) zu realisieren.
2. Verbindungsmodul (3) nach Anspruch 1, dadurch
gekennzeichnet, dass das an das SOA-Netzwerk (4)
anzubindende Gerät (2) einen Sensor, Effektor oder
Aktuator umfasst.
3. Verbindungsmodul (3) nach Anspruch 1 oder 2, dadurch
gekennzeichnet, dass die erste Schnittstelle (3.2) eine RS232-Schnittstelle, eine USB-Schnittstelle, eine LAN- Anbindung, eine Ethernet-Anbindung oder eine optische Anbindung umfasst.
4. Verbindungsmodul (3) nach Anspruch 1 oder 2, dadurch
gekennzeichnet, dass die zweite Schnittstelle (3.4) eine Busanbindung, insbesondere eine CAN-, TTCAN-, LIN-, MOST-, ByteFlight-, D2B-Optical- oder FlexRay- Busanbindung umfasst.
5. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die zweite Schnittstelle (3.4) als eine Funk-Schnittstelle ausgebildet ist.
6. Verbindungsmodul (3) nach Anspruch 4, dadurch
gekennzeichnet, dass die Funk-Schnittstelle (3.4) zur Datenübertragung zwischen dem Verbindungsmodul (3) und dem SOA-Netzwerk (4) mit kurzer Verzögerungszeit, insbesondere in Echtzeit, ausgebildet ist.
7. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Rechengerät (7) zum Abarbeiten des Computerprogramms als ein Mikroprozessor ausgebildet ist.
8. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Rechengerät (7) zum Abarbeiten des Computerprogramms als ein Digitaler
Signalprozessor, genannt DSP, ausgebildet ist.
9. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass das Rechengerät (7) die erste und/oder die zweite Schnittstelle (3.2; 3.4) steuert .
10. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass das Rechengerät (7) die erste und/oder die zweite Schnittstelle (3.2; 3.4) nicht ansteuert und dass das Verbindungsmodul (3) ein weiteres Rechengerät, insbesondere einen Digitalen
Signalprozessor, genannt DSP, aufweist, welches die erste und/oder die zweite Schnittstelle (3.2; 3.4) steuert .
11. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass das Verbindungsmodul (3) einen Watchdog-Timer (15) aufweist.
12. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass im Rahmen der Anpassung der auf dem mindestens einen Gerät (2) vorhanden Firmware an das SOA-Netzwerk (4) automatisch eine Heartbeat- Operation erzeugt und implementiert.
13. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass zur Anpassung der auf dem mindestens einen Gerät (2) vorhanden Firmware an das SOA-Netzwerk (4) durch einen Gerätehersteller bei diesem kein Wissen über SOA vorhanden sein muss.
14. Verbindungsmodul (3) nach Anspruch 13, dadurch
gekennzeichnet, dass zur Anpassung der auf dem
mindestens einen Gerät (2) vorhanden Firmware an das SOA-Netzwerk (4) durch den Gerätehersteller bei diesem kein Wissen über eine Zustandsbehaftung der Geräte (2) und eine Zustandslosigkeit von Services in dem SOA- Umfeld des SOA-Net zwerks (4) und die Berücksichtigung der Services vorhanden sein muss.
15. Verbindungsmodul (3) nach Anspruch 14, dadurch
gekennzeichnet, dass das Verbindungsmodul (3) SOA- Aufrufe aus dem SOA-Netzwerk (4) abspeichert und
koordiniert abarbeitet.
16. Verbindungsmodul (3) nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dadurch gekennzeichnet, dass zur Anpassung der auf dem mindestens einen Gerät (2)
vorhanden Firmware an das SOA-Netzwerk (4) durch den Gerätehersteller bei diesem lediglich Wissen über
Schnittstellen des zu kapselnden Geräts (2) und über eine Programmiersprache eines im Rahmen der Anpassung generierten Kapselungsgerüsts vorhanden ist.
17. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass eine SOA-Kapselung einer Funktionalität des Geräts (2) derart realisiert ist, dass die SOA-Kapselung Prioritäten von SOA-Aufrufen aus dem SOA-Netzwerk (4) dahingehend verarbeiten kann, dass die den SOA-Aufrufen entsprechenden Funktionalitäten des Geräts (2) in einer den Prioritäten entsprechenden
Reihenfolge abarbeitbar sind.
18. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, dass das Verbindungsmodul (3) eine von den anderen Komponenten des Verbindungsmoduls (3) abgetrennte Sandbox (11) aufweist, in der die
Anpassungen der Geräte (2) an das SOA-Netzwerk (4) gespeichert sind.
19. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 18, dadurch gekennzeichnet, dass die Anpassungen der Geräte (2) an das SOA-Netzwerk (4) durch Dienstebeschreibungen realisiert sind, die in einer Service Registry (21) des Verbindungsmoduls (3) gespeichert sind.
20. Verbindungsmodul (3) nach Anspruch 19, dadurch
gekennzeichnet, dass die Service Registry (21) für unterschiedliche SOA-Netwerke (4) eine passende SDL (Web-Service Definition Language ) -Datei liefert.
21. Verbindungsmodul (3) dadurch gekennzeichnet, dass
mehrere Versionen der Anpassung eines Geräts (2)
parallel betrieben werden können, sodass SOA- Applikationen die auf alte Anpassungen basieren
unterstützt werden können.
22. Verbindungsmodul (3) nach einem der Ansprüche 1 bis 21, dadurch gekennzeichnet, dass das Verbindungsmodul (3) Mittel aufweist, um Fehler, die in der Anpassung des Geräts (2) an das SOA-Umfeld auftreten, in
Fehlernachrichten zu konvertieren, so dass das SOA- Netzwerk (4) diese Fehlernachrichten verarbeiten kann.
23. Verbindungsmodul (3) nach einem der Ansprüche 4 bis 22, dadurch gekennzeichnet, dass das Verbindungsmodul (3) eine erste oduleinheit (10), welche das angeschlossene Gerät (2) als einen Dienst im SOA-Net zwerk (4) abbildet, sowie eine zweite Moduleinheit (22) umfasst, welche den durch die erste Moduleinheit (10) abgebildeten Dienst für eine Übertragung über ein Funknetz (35) mit
niedriger Bandbreite unter Beibehaltung der SOA- Funktionalität aufbereitet.
24. Verbindungsmodul (3) nach Anspruch 23, dadurch
gekennzeichnet, dass die zweite Moduleinheit (22), welche das Konsumieren von SOA-Anpassungen über das Funknetz (35) ermöglicht, Anforderungen der
militärischen Welt erfüllt, insbesondere hinsichtlich eines vereinfachten aber robusten Sicherheitskonzepts (30), einer militärischen Verschlüsselung (28) der
Daten, verteilter Service Registries (26; 26' ) , die auf Anforderung zwischen den Verbindungsmodulen (3; 3' ) synchronisierbar (25; 26) ist und einer Steuerung (29) eines Datenflusses mit reduzierter Bandbreite über das Funknetz (35) .
25. Verbindungsmodul (3) nach Anspruch 23 oder 24, dadurch gekennzeichnet, dass die zweite Moduleinheit (22), welche das Konsumieren von SOA-Anpassungen über das Funknetz (35) ermöglicht, einen Radio Adapter (31) zum Anschluss herkömmlicher Funkgeräte (34) der
militärischen Welt aufweist.
EP10795250A 2010-01-19 2010-12-18 Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk Ceased EP2526487A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102010005658A DE102010005658A1 (de) 2010-01-19 2010-01-19 Verbindungsmodul zum Anbinden mindestens eines Sensors, Aktors oder Effektors an ein Service Oriented Architecture- (SOA-) Netzwerk
PCT/EP2010/007768 WO2011088878A1 (de) 2010-01-19 2010-12-18 Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk

Publications (1)

Publication Number Publication Date
EP2526487A1 true EP2526487A1 (de) 2012-11-28

Family

ID=43901467

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10795250A Ceased EP2526487A1 (de) 2010-01-19 2010-12-18 Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk

Country Status (9)

Country Link
US (1) US8751707B2 (de)
EP (1) EP2526487A1 (de)
KR (1) KR101471729B1 (de)
AU (2) AU2010342846A1 (de)
CA (1) CA2787187C (de)
DE (1) DE102010005658A1 (de)
MY (1) MY156721A (de)
SG (1) SG182603A1 (de)
WO (1) WO2011088878A1 (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8458313B2 (en) * 2009-09-11 2013-06-04 Global Pay, Inc. Synchronization of data among disparate data sources
JP5385751B2 (ja) * 2009-10-14 2014-01-08 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワーク・ユーザに、ネットワーク上の各機器から提供されるサービスの利用コストを提示する方法、コンピュータ・プログラム及び装置
JP2011086055A (ja) * 2009-10-14 2011-04-28 Internatl Business Mach Corp <Ibm> ネットワーク上の機器の動作状態を、ネットワークの利用者数に応じて変化させる、機器管理方法、コンピュータ・プログラム及び装置
US20120078809A1 (en) * 2010-09-27 2012-03-29 Sap Ag Integrating sub-processes in business process modeling notation processes
US20150197154A1 (en) * 2010-12-24 2015-07-16 Martin Kelly Jones Selection of battery remediation type and/or battery remediation station based upon available time period at location
US20150191095A1 (en) * 2010-12-24 2015-07-09 Martin Kelly Jones Authentication Methods for Battery Remediation in Connection with Electric Powered Mobile Thing (EPMT)
DE102011007914A1 (de) * 2011-04-21 2012-10-25 Deere & Company Datenkommunikationsschnittstelle für ein landwirtschaftliches Nutzfahrzeug
EP2557752B1 (de) * 2011-08-11 2017-09-27 Siemens Aktiengesellschaft Verfahren und vorrichtung zum herstellen einer end-zu-end-kommunikation zwischen zwei netzwerken
US9088514B2 (en) * 2012-07-23 2015-07-21 Broadcom Corporation Flexray communications using ethernet
CN103518342B (zh) * 2013-04-26 2016-09-28 华为技术有限公司 一种心跳信号的发送控制方法及装置
KR101517503B1 (ko) * 2013-09-26 2015-05-06 주식회사 비트앤펄스 사물지능통신 및 사물인터넷을 위한 광대역모뎀 기반 다중센서장비 제어시스템
DE102014007308A1 (de) 2014-05-17 2015-11-19 Diehl Bgt Defence Gmbh & Co. Kg Verfahren zum Betreiben eines bodengebundenen Luftabwehrsystems
US10165095B2 (en) * 2015-06-22 2018-12-25 Rockwell Automation Technologies, Inc. Active report of event and data
EP3396549A1 (de) * 2017-04-28 2018-10-31 dSPACE digital signal processing and control engineering GmbH Adapter für die verbindung eines eingebetteten systems mit einem bedienrechner und verfahren zum anpassen eines adapters
DE102018109831A1 (de) 2017-04-28 2018-10-31 Dspace Digital Signal Processing And Control Engineering Gmbh Adapter für die Verbindung eines eingebetteten Systems mit einem Bedienrechner und Verfahren zum Anpassen eines Adapters
US10640328B2 (en) * 2017-12-13 2020-05-05 Thyssenkrupp Elevator Ag System for compiling and transferring elevator configuration data and methods of using same
DE102018008521A1 (de) * 2018-10-30 2020-04-30 Mbda Deutschland Gmbh Kommunikationssystem fuer ein taktisches Luftverteidigungssystem
CA3084976A1 (en) * 2019-07-01 2021-01-01 Next Pathway Inc. System and method for automated source code generation to provide service layer functionality for legacy computing systems in a service-oriented architecture
CN114342447B (zh) * 2019-09-06 2023-08-29 上海诺基亚贝尔股份有限公司 管理用于通信监督的通知
DE102020104408A1 (de) * 2020-02-19 2021-08-19 HELLA GmbH & Co. KGaA Fahrzeugkomponente zur Bereitstellung wenigstens eines Dienstes in einem Fahrzeug mit einer Vorfiltereinheit

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070236346A1 (en) * 2006-02-21 2007-10-11 Abdelsalam Helal Modular Platform Enabling Heterogeneous Devices, Sensors and Actuators to Integrate Automatically Into Heterogeneous Networks

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003017123A1 (en) * 2001-08-16 2003-02-27 Redline Networks, Inc. System and method for maintaining statefulness during client-server interactions
US7392391B2 (en) * 2001-11-01 2008-06-24 International Business Machines Corporation System and method for secure configuration of sensitive web services
TWI236853B (en) * 2002-10-02 2005-07-21 Mitsubishi Electric Corp Communication adapter device, communication adapter, method for writing into nonvolatile memory, electric apparatus used for the same, and ROM writer
KR100701421B1 (ko) * 2004-12-09 2007-03-30 한국전자통신연구원 가상의 통신 모듈 및 이를 이용한 통신 프로토콜 검증방법
US20060282886A1 (en) 2005-06-09 2006-12-14 Lockheed Martin Corporation Service oriented security device management network
US20070069896A1 (en) 2005-09-27 2007-03-29 Bea Systems, Inc. RFID system using SOA
JP2007280030A (ja) * 2006-04-06 2007-10-25 Canon Inc 通信装置、通信装置の制御方法、及びコンピュータプログラム
DE102006047114A1 (de) * 2006-09-27 2008-04-03 T-Mobile International Ag & Co. Kg Verfahren zur Bereitstellung eines konvergenten Nachrichtendienstes für mindestens ein Endgerät in einem Mobilfunknetzsystem und entsprechende Arbeitseinheit
US7535684B2 (en) * 2007-01-09 2009-05-19 Honeywell International Inc. Overspeed protection for sensorless electric drives
WO2008126325A1 (ja) * 2007-03-30 2008-10-23 Fujitsu Limited クラスタシステム、ソフトウェア更新方法、サービス提供ノード、およびサービス提供用プログラム
EP2045140B1 (de) * 2007-10-01 2010-01-27 Harman/Becker Automotive Systems GmbH Sprachgesteuerte Einstellung von Fahrzeugteilen
US8069057B2 (en) 2008-04-07 2011-11-29 General Electric Company Systems and methods for providing healthcare asset intelligence using service-oriented architecture and service-oriented computing
FR2930663A1 (fr) 2008-04-25 2009-10-30 Thales Sa Procede pour gerer des equipements cryptographiques avec une administration unifiee
US8140615B2 (en) 2008-05-07 2012-03-20 International Business Machines Corporation Consolidated business service for integrating service oriented architecture services with customer resources
US8255972B2 (en) * 2008-06-06 2012-08-28 International Business Machines Corporation Method to automatically map business function level policies to it management policies
US8156140B2 (en) * 2009-11-24 2012-04-10 International Business Machines Corporation Service oriented architecture enterprise service bus with advanced virtualization
US8364745B2 (en) * 2009-11-24 2013-01-29 International Business Machines Corporation Service oriented architecture enterprise service bus with universal ports

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070236346A1 (en) * 2006-02-21 2007-10-11 Abdelsalam Helal Modular Platform Enabling Heterogeneous Devices, Sensors and Actuators to Integrate Automatically Into Heterogeneous Networks

Also Published As

Publication number Publication date
AU2010342846A2 (en) 2012-09-27
AU2015100676B4 (en) 2015-07-16
CA2787187A1 (en) 2011-07-28
DE102010005658A1 (de) 2011-07-21
AU2015100676A4 (en) 2015-06-18
KR20120129913A (ko) 2012-11-28
MY156721A (en) 2016-03-15
AU2010342846A1 (en) 2012-09-06
US20120290749A1 (en) 2012-11-15
SG182603A1 (en) 2012-08-30
WO2011088878A1 (de) 2011-07-28
KR101471729B1 (ko) 2014-12-10
CA2787187C (en) 2016-05-10
US8751707B2 (en) 2014-06-10

Similar Documents

Publication Publication Date Title
EP2526487A1 (de) Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk
DE102017124844A1 (de) Sicheres Transportieren von Daten über eine Datendiode für gesicherte Prozesssteuerungskommunikationen
DE102017124821A1 (de) Veröffentlichung von daten über eine datendiode für gesicherte prozesssteuerungskommunikationen
DE60101566T2 (de) Gerätetreibererzeugung
EP3230856B1 (de) Verfahren zum update von firmware von geräten
EP2719125B1 (de) Vorrichtung und verfahren zur skriptgesteuerten datenverarbeitung von daten für ein hauskommunikations- oder hausautomationssystem
EP3834373B1 (de) Verfahren zum automatischen konfigurieren eines systems, system und computerlesbares medium
DE102019103927A1 (de) Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan
EP1416400B1 (de) System und Verfahren zur Bereitstellung von Daten und Diensten für Geräte über öffentliche Netze, sowie Gerät, welches die bereitgestellten Daten und Dienste verwendet
WO2010043629A1 (de) Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system
DE102019100436A1 (de) System zum dynamischen zuweisen von diensten zwischen steuerungen in einem automobil
DE102015215480A1 (de) Verfahren und Vorrichtung zum Übertragen einer Nachricht in einem Fahrzeug
DE102014219472A1 (de) Verfahren zum Übertragen von Daten, Netzknoten und Netzwerk
DE602004009746T2 (de) Teilen von Diensten in einem Netz
DE102021123538A1 (de) Sicherheitssysteme zum einsatz beim implementieren von sehr vielseitigen feldgeräten und kommunikationsnetzwerken in steuerungs- und automationssystemen
DE602005005435T2 (de) System und Verfahren zur Kommunikationsverwaltung von Komponentenanwendungen
EP3105898B1 (de) Verfahren zur kommunikation zwischen abgesicherten computersystemen sowie computernetz-infrastruktur
DE102016008957B4 (de) Direkter Zugriff auf Bussignale in einem Kraftfahrzeug
DE10229878A1 (de) Automatisierungsgerät mit Schnittstelle zum nachrichten- und portbasierten Zugriff auf eine Applikation
EP3945702A1 (de) Kanalbasierte kommunikation in einem iot-netzwerk
DE102004039633A1 (de) Verfahren und Vorrichtung zum Austauschen fahrzeugoriginärer Informationen
EP1499963A2 (de) Automatisierungsgerät mit schnittstelle zum nachrichten- und portbasierten zugriff auf eine applikation
DE102016101729B4 (de) IoT-Hardware-Modul, Funktionseinheit für IoT-Anwendungen mit einem solchen IoT-Hardware-Modul sowie System für IoT-Anwendungen mit mehreren solchen Funktionseinheiten
DE102019202134A1 (de) Verfahren und Vorrichtung zum Übertragen und zum Bereitstellen von Daten in einem Publish-Subscribe-System
WO2022238482A1 (de) Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20120514

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20150122

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170724