WO2007020207A1

WO2007020207A1 - Method for coordinating decentralized systems for an event management

Info

Publication number: WO2007020207A1
Application number: PCT/EP2006/065116
Authority: WO
Inventors: Thorbjörn Hansen; Manfred Langen; Christian Pöttinger
Original assignee: Siemens Aktiengesellschaft
Priority date: 2005-08-17
Filing date: 2006-08-07
Publication date: 2007-02-22
Also published as: DE102005038911A1

Abstract

The invention relates to a method for coordinating decentralized systems for an event management, during which time data and action patterns for planning and carrying out an event are electronically stored in a planning system for planning and carrying out an event. Process steps for planning and carrying out the event in the decentralized systems are coordinated by using the time data and action patterns in that instructions from a predetermined set of instructions are exchanged via a uniform interface between the planning system and the decentralized systems.

Description

description

Procedure for coordinating decentralized systems for event management

The invention relates to a method for coordinating decentralized systems for event management. The events are large events, such as Olympic Games, World Championships, concerts or conferences. Venues for this include stadiums, arenas, halls or multi-functional halls or arenas, as well as fairs. To manage such an event, a number of decentralized systems need to be coordinated. The decentralized systems are applications from the areas of ticket sales, access control for spectators,

Access control for accredited persons such as employees, athletes, press or VIPs, electronic payment, call center, control center for security, fire protection or ambulance, parking management, public transport and much more. In most of these decentralized systems, large amounts of data are processed, sometimes with high time requirements. For example, in a stadium for 100,000 spectators, every 100,000 spectator tickets in a time window have to be checked electronically for access control hours. Furthermore, a ticket sold at the venue must be transmitted directly from ticket sales to access control, as access control takes place directly after the ticket sale. Accreditation can also include tens of thousands of people at a large event.

To ensure that the event runs smoothly, it is necessary for decentralized systems to have consistent data sets that are synchronized with each other. Because of the high data volumes and the time requirements, this can only be done by electronic communication between the decentralized systems. Such communication takes place in the prior art only bilaterally between access control and ticket sales. Today's decentralized systems have very different interfaces. This complicates the planning and execution of events, as they are associated with complex processes. Coordinating the decentralized systems for planning and executing an event is thus only possible with considerable personnel expenditure. To date, this domain has mainly worked manually with Excel-based checklists.

It is therefore the task to specify a method for the coordination of decentralized systems for an event management, with which the previously manual and therefore complex planning processes can be automated.

This object is achieved by the method according to claim 1. Preferred developments emerge from the dependent claims.

In the method for coordinating decentralized systems for event management, time data and action patterns for planning and executing an event are electronically stored in a planning system. Using the time data and action patterns, process steps for planning and executing the event in the decentralized systems are coordinated by exchanging commands from a given command set via a uniform interface between the planning system and the decentralized systems.

The computer program is processed in a processor and executes the procedure.

The computer-readable medium stores a computer program which executes the method when it is executed in a processor. The method has the advantage that consistent data sets can be produced in the decentralized systems, even though the decentralized systems are independent units. Furthermore, it becomes possible to co-ordinate the decentralized systems according to a predetermined action pattern. The process thus supports efficient planning of a wide variety of event types and handles all automatable process steps in the context of event management. Thus, an integrated solution for event management is created via the uniform interface and the planning system. The uniform interface enables the highest possible flexibility and interchangeability among the decentralized systems. This is particularly advantageous because there are a large number of small and changing providers on the market for decentralized systems. The use of a given instruction set enables standardization and optimization of the uniform interface.

In a continuing education is in the planning system for each

Event an event-related record containing event date, event status and event type is stored.

By including these three fields in a corresponding record, there is the advantage that these fields as

Basic parameters for the coordination of decentralized systems can be used.

In a special development, an action pattern is selected for the planning and execution of the event, which corresponds to the event type.

This development offers the advantage that for different types of events, such as concerts, football matches or trade fairs, specific action patterns can be stored in the planning system and used to plan and execute an event with the respective event type. According to one embodiment, the action patterns are fixed or can be adapted by a user.

The embodiment offers the advantage that predefined action patterns can either be made available in accordance with the respective event type or else can be individually adapted to the respective event by a user.

According to another embodiment, a decentralized system synchronizes its own data

Data files of the other decentralized systems and the planning system via a command from the given instruction set.

The advantage of this embodiment is that, for example, an event can be canceled if four weeks before the event has not yet been sold a predetermined percentage of tickets. In this case, ticket sales sends a corresponding command to the planning system and the other remote systems to cancel the event.

In a further development, the process steps in the decentralized systems are triggered by time-dependent triggers or user interactions in the planning system.

This development offers the advantage that the process steps can be advanced automatically or by user input according to the respective requirements.

According to a particular embodiment, the

Process steps are triggered as a function of one of the action patterns (130) and current values of fields of the event-related data record.

This embodiment makes it possible in particular, the

Perform event management dynamically based on the action patterns and about the current event status. For example, if the event status changes from optional to mandatory, more will be added Process steps triggered, which require a binding status of the event. This includes about the ticket sale.

According to a further development, in addition to the time data and action patterns, ancillary conditions are taken into account in the coordination of the process steps.

This offers the advantage that any necessary periods of time between events can be scheduled, for example due to setup and dismantling times. The automatic consideration of constraints ensures that the time data in the planning system are not only kept consistent with the data of the decentralized systems, but are also realistic in terms of the implementation of the event.

In a further development, the time data or action patterns are displayed on a user interface for a user.

This offers the advantage that the time data can be displayed clearly in the form of a calendar. Furthermore, the action patterns can be visualized and edited by a user. The user interface can also display the constraints and allow them to be edited.

According to one embodiment, each of the decentralized systems has its own control component.

This embodiment offers the advantage that the

Planning system can be designed specifically for a higher-level coordination of decentralized systems. Thus, even when changing or canceling an event only relevant information must be passed through the planning system to the decentralized systems. All further, often very complex follow-up actions are then carried out independently by the decentralized systems. In the following the invention is based on

Embodiments explained in more detail, which are shown schematically in the drawing. It shows:

FIG. 1 shows an integrated event management system,

FIG. 2 shows an action pattern,

FIG. 3 shows tables for processing an action pattern.

1 shows an embodiment of the invention, here an example architecture for an integrated event management system 9. The integrated event management system 9 consists of a planning system 1 and decentralized systems 2. The planning system 1 and the decentralized systems 2 are connected via a uniform interface 3 , The uniform interface 3 can be implemented, for example, as shared middleware (hardware and / or software for communication between the planning system 1 and the decentralized systems 2). The uniform interface 3 provides individual interfaces to the respective decentralized systems 2, since these often have proprietary data formats and communication protocols. Such individual interfaces can be implemented as connectors, for example.

Data is exchanged bidirectionally between the decentralized systems 2 with one another and between the decentralized systems 2 and the planning system 1 via the uniform interface 3. The decentralized systems 2 are independent units, which usually have their own databases and local control components.

A graphical user interface (GUI), here a portal framework GUI 7, provides unified access to all systems. GUI integration interfaces 6 bind the respective systems to the Protal Framework GUI 7. An evaluation module 5 provides a common functionality Observe (Activity Monitoring) and Report (Reporting) ready. All systems access shared data stores and services 4. A single sign-on service 8 can be used for a uniform authentication mechanism for all systems in the framework of the portal framework GUI 7. FIG. 1 thus shows an overall architecture which provides an integration solution for event management. The GUI integration interface 6 can for example use the protocols and programming languages HTTP, HTML, CSS or JAVA script and provide options for personalization and standardization of the user interfaces of the individual systems. The single sign-on service 8 can be implemented via LDAP or PKI, for example. The uniform interface 3 may be based on XML or web services.

The planning system 1 consists of an event data GUI 11, ie a user interface, which allows the input, display and editing of all event-related data. For this purpose, the planning system 1 manages an event-specific data record for each event, which characterizes the respective event. For each event, for example, an associated date, an event status and an event type can be stored in the fields of the event-specific data record. Other possible fields are name, organizer or series type. This data can be captured and edited using the Event Data GUI 11.

Furthermore, the planning system 1 has a calendar module 12. In the calendar module 12, for example, time data 120 are stored for an event. The calendar module also serves for temporal organization and visualization of the events.

Third, the planning system 1 includes an action pattern module 13. In the action pattern module 13, action patterns 130 are electronically stored. These can in turn be displayed to a user via a user interface or made available for editing. An action pattern (Workflow) describes process steps that are required for the planning and execution of an event. The action patterns can optionally take into account compliance with constraints, such as minimum time intervals between events.

The planning system 1 provides automatic control for the planning and execution of the events by coordinating the decentralized systems 2. The decentralized systems 2 are in detail one

Access control system 21, an accreditation system 22, an electronic payment system 23, a ticket sales system 24, an event contact center 25 and a control center 26. Since the decentralized systems 2 are independent units that perform the individual process steps independently, the planning system 1 assumes only the Coordination of the decentralized systems 2 and the triggering of the individual process steps as a function of the time data 120 and action patterns 130.

The architecture shown in Figure 1 is to be understood as an example only. Of course, individual modules or systems can be added or omitted.

Fields such as the event status or the event type in the event-specific data record can be taken into account as basic parameters during the execution of the action pattern 130 by the planning system 1. Thus, for example, each action pattern 130 is related to a specific type of event (concert, football match, fair ...) and is selected by the planning system 1 or a user for the planning and execution of the event, depending on this. The selected action pattern indicates which of the decentralized systems 2 must be included in the respective scenario. Furthermore, the action pattern contains temporal conditions relative to the time at which the respective event should take place. Thus, the action pattern may indicate, for example, that the ticket sale 6 weeks before the date of the event should begin. Furthermore, the action patterns in the system can be preset or adapted by a user. In the first variant, the planning system 1 is offered during the installation with a fixed set of action patterns, from which suitable action patterns can be selected for a particular event depending on its event type. The second variant is a generic system in which users can create 1 new action patterns or edit existing action patterns at runtime of the planning system.

The event status indicates whether the date planned for an event is still optional (for example, planned) or already binding (usually contractually agreed). The event status can also indicate with a value between 0 and 1 a probability that the event will take place. For the coordination of the process steps in the decentralized systems 2 the event status plays an important role. Thus, not all decentralized systems 2 will be informed with optional event status, because about one

Ticket trading would be pointless at this stage. However, it is already possible to check at this stage whether temporal secondary conditions are fulfilled which can indicate, for example, that certain intervals must be taken into account between two events, depending on their type of event, because of downtime, extension or conversion times. For example, at a stage in the evening, no big rock concert will take place when a football game is played in the afternoon. The planning system 1 continuously monitors the event status. As soon as the event status changes, for example, by a confirmation from optional to binding, further process steps are triggered in the decentralized systems 2. For example, 24 necessary data can be transmitted to the ticket sales system in order to start the presale, as soon as the date for the event has been contractually agreed.

Similarly, the control center 26 can be informed at this time, for example, authorities and public Public transport about the planned event.

In a concrete scenario a concert should be held. For this an action pattern is selected, which is tailored to the event type concert. The action pattern stipulates that ticket sales should begin six weeks before the concert date. Accordingly, the planning system 1 ensures that the corresponding data are transmitted in good time to the ticket sales system 24 in accordance with this predetermined deadline. The prerequisite for this, however, may be that the event status is binding. However, if the event status is still optional seven weeks before the scheduled concert date, for example, corresponding alarms can be generated or the

Planning the event to be automatically canceled. If necessary, the participating decentralized systems 2 are informed about this.

Conversely, a decentralized system 2 can also influence the planning system 1. This makes sense, for example, if a current progress, for example in the sale of tickets, is below a predetermined threshold compared with a business-oriented variable, for example a minimum sales figure in relation to the remaining time. If, for example, four weeks before a planned event date a predetermined percentage of the tickets have not yet been sold, the event can be canceled by the ticket sales system 24 by sending a corresponding command to the planning system 1.

The commands are transmitted here as data transfers via the uniform interface 3. For this a small and uniform instruction set is used. Using the commands, a consistent state can be established in all systems. The coordination of the process steps can be initiated either by time-dependent triggers or user interactions, which are determined by the respective action patterns are given. Here, the current values of the basic parameters, such as the event status, are always taken into account.

For example, commands to synchronize event record fields may be as follows:

- New Event (Create a new event-specific record)

- Update event (change fields of the event-specific data record)

- delete event (delete the event specific record)

- Show event (displaying the event-specific data record)

With the help of this instruction set, changes to an event-specific data record can be forwarded immediately to all affected decentralized systems. This ensures consistency of the event-specific data in all decentralized systems.

Analogously, the instruction set contains further commands for the comparison of other data, such as personal data for contacts to various roles such as operator, organizer, sponsor, catering, etc.

In the following, a second embodiment will be described, which explains the execution of an action pattern by the planning system 1 in more detail. FIG. 2 shows a graphic representation 30 of an action pattern. Graph 30 includes a flowchart that includes an action pattern from the definition of a new event to its completion. For each individual step in the action pattern, a designation of the step, its participants, the actions to be performed as well as preconditions to be checked are assigned and stored in the action pattern. The steps are steps that the planning system 1 or a user of the planning system 1 executes. The steps can be here Initiate or coordinate process steps in the decentralized systems 2.

The graphic representation 30 in FIG. 2 shows a step 31 at the beginning of the action pattern. In step 31, necessary information for a new event is entered in a corresponding form in the event data GUI 11 by a user. The event status is defined as optional. This is followed by a state transition 311, in which an event-specific data record is created and stored in one

Data memory is stored. The action pattern now optionally continues with a step 321 or 322. In step 321, the planning system 1 sends a message (such as an e-mail) to an event manager. In step 322, the planning system 1 sends a message to a promoter. The

Message contains a booking information for the event. Subsequently, a condition 323 is checked, which requests that the event status has become binding. In a following step 33, an event manager enters missing information in an input form in the event data GUI 11 and confirms the booking. In addition, in a step 331 further events with optional event status, which overlap in time with the event being processed, are canceled by the planning system 1. A notification about this occurs in a step 332, in which the planning system 1 informs promoters of the other events by means of a rejection message. In this case, the optional other events can be automatically removed from the calendar module 12. Step 33 is further followed by a step 34 in which the ticket sales system 24 is provided with the necessary information by the planning system 1 to start ticket sales for the processed event. Once condition 35 is fulfilled, which requires the scheduled date for the event to be less than six weeks in the future, step 36 is executed. In this sends that

Planning system 1 a message to the event manager. This is in a subsequent step 37 information according to a checklist for the control center 26 in an input form in the event data GUI 11. Subsequently, the planning system 1 forwards the input information to the control center 26 in a step 38. Finally, a condition 39 is checked, which is then fulfilled if the current data corresponds to the planned date for the event. Subsequently, step 40 is executed, in which necessary information is forwarded to the access control system 21.

The described action pattern as well as the individual steps are only to be understood as an example. Of course, the accreditation system 22 can also be included analogously to step 38 in an analogous manner. The same applies to all other decentralized systems 2.

In a third exemplary embodiment, an action pattern for the cancellation of an event with a binding event status is described below. In this case, all decentralized systems 2, which were already included in the planning of the event, must be informed of its cancellation. This case is therefore more complicated than the cancellation of an event with an optional event status, which can be done internally in the calendar module 12 of the planning system 1 without further information to the decentralized systems 2.

According to the third embodiment, a user makes an input in the event data GUI 11, with which the event-related record in the data memory of the planning system 1 is deleted. Subsequently, the planning system 1 sends a message to the promoter. Then send that

Planning system 1 a command to the ticket sales system 24 to inform him about the cancellation of the event. If the control center 26 has already been involved, a corresponding command is also sent to the control center 26. Analogously, corresponding commands are also sent to the

Accreditation system 22 and the access control system 21 and any other decentralized systems 2 sent if these were already involved in the planning of the event.

Notwithstanding this embodiment, the cancellation of the event does not have to be done by a user of the planning system 1. The rejection can also be done by a user such as the control center 26, here for security reasons, for example. Furthermore, a physical sensor, which is connected to the control center and measures the wetness of a lawn approximately in a football stadium, via the control center 26 cause a cancellation of the event when about prolonged rain makes a planned football match impossible. In this case, the service provider 26 sends a corresponding command to the planning system 1, whereupon this deletes the event-specific data record.

According to a fourth embodiment, an action pattern is described below, which includes the change of an event with a binding event status. This action pattern consists of a combination of the action patterns of the second and third embodiments. First, the action pattern of the third embodiment is executed to first clear the event to be changed. Subsequently, the action pattern from the second embodiment is executed to re-create the event in the changed form.

Changes to events with optional event status can be made internally in the calendar module of planning system 1. No action pattern is required for this because no decentralized systems 2 are involved at this stage.

FIG. 3 shows two tables as they can be used in the context of the event data GUI 11 for visualizing and processing the event-specific data records and action patterns. For example, in the upper table, line 51 may include an identifier for the currently displayed or edited action pattern. Line 52 may be titled Action pattern are occupied. Furthermore, line 53 may include a description of the action pattern. Line 54 contains the status of the action pattern, which is determined by an element of the set {in progress, wait, done, completed}. Finally, line 55 may contain comments on the respective action pattern.

In the lower table in FIG. 3, the actual steps of the action pattern are now shown in a row in each case. Column 61 contains information about its position in the action pattern for each step. Corresponding coding ensures that steps can be distinguished as to whether they are to be executed in parallel, alternatively or in succession. In column 62, a name of the respective step is listed. Column 63 contains a note as to whether the respective step has already been completed. Column 64 may contain a deadline for each step. Column 65 contains the respective editor. Column 66 serves as a comment. Column 67 contains the completion date. Column 68 contains a

Button with which the respective step can be edited, for example.

The mentioned embodiments can be freely combined with each other.

Claims

claims

1. A method for coordinating decentralized systems for an event management, - in which time data (120) and action patterns (130) for the planning and execution of an event are stored electronically in a planning system (1);

in which, based on the time data (120) and action pattern (130), process steps for planning and execution of the event in the decentralized systems (2) are coordinated by issuing commands from a predetermined command set via a uniform interface (3) between the planning system

(1) and the decentralized systems (2).

2. The method of claim 1, wherein in the planning system (1) for each event, an event-related record is stored, which contains a date of the event, an event status and an event type.

3. The method of claim 2, wherein an action pattern for the planning and implementation of the event is selected, which corresponds to the event type.

4. The method of claim 1, wherein the action pattern (130) are fixed or can be adapted by a user.

5. The method of claim 1, wherein a decentralized system

(2) synchronized by a command from the predetermined command set on the uniform interface (3) own data with data in the other decentralized systems (2) and the planning system (1).

6. The method of claim 1, wherein the process steps in the decentralized systems (2) by time-dependent trigger or

User interactions in the planning system (1) are triggered.

The method of claim 1, wherein the process steps are triggered in response to one of the action patterns (130) and current values of fields of the event related data set.

8. The method of claim 1, wherein in addition to the time data (120) and action patterns (130) constraints in the

Coordination of process steps are taken into account.

9. The method of claim 1, wherein the time data or

Action patterns are displayed on a user interface for a user.

10. The method of claim 1, wherein each of the distributed systems has its own control component.

11. Computer program, which is processed in a processor and thereby performs the method according to one of the preceding claims.

12. Computer-readable data carrier, on which a computer program is stored, which carries out the method according to claim 1 to 10, when it is processed in a processor.