[go: up one dir, main page]

WO2007020207A1 - Procede pour coordonner des systemes decentralises pour gerer des evenements - Google Patents

Procede pour coordonner des systemes decentralises pour gerer des evenements Download PDF

Info

Publication number
WO2007020207A1
WO2007020207A1 PCT/EP2006/065116 EP2006065116W WO2007020207A1 WO 2007020207 A1 WO2007020207 A1 WO 2007020207A1 EP 2006065116 W EP2006065116 W EP 2006065116W WO 2007020207 A1 WO2007020207 A1 WO 2007020207A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
planning
decentralized systems
planning system
data
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
PCT/EP2006/065116
Other languages
German (de)
English (en)
Inventor
Thorbjörn Hansen
Manfred Langen
Christian Pöttinger
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.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of WO2007020207A1 publication Critical patent/WO2007020207A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management

Definitions

  • 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.
  • venues for this include stadiums, arenas, halls or multi-functional halls or arenas, as well as fairs.
  • 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.
  • 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.
  • 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.
  • time data and action patterns for planning and executing an event are electronically stored in a planning system.
  • 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.
  • 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.
  • Event an event-related record containing event date, event status and event type is stored.
  • an action pattern is selected for the planning and execution of the event, which corresponds to the event type.
  • 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.
  • a decentralized system synchronizes its own data
  • 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.
  • ticket sales sends a corresponding command to the planning system and the other remote systems to cancel the event.
  • process steps in the decentralized systems are triggered by time-dependent triggers or user interactions in the planning system.
  • 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
  • ancillary conditions are taken into account in the coordination of the process steps.
  • time data or action patterns are displayed on a user interface for a user.
  • time data can be displayed clearly in the form of a calendar.
  • action patterns can be visualized and edited by a user.
  • the user interface can also display the constraints and allow them to be edited.
  • each of the decentralized systems has its own control component.
  • 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
  • FIG. 1 shows an integrated event management system
  • FIG. 2 shows an action pattern
  • FIG. 3 shows tables for processing an action pattern.
  • 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.
  • the decentralized systems 2 are independent units, which usually have their own databases and local control components.
  • GUI graphical user interface
  • 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.
  • the planning system 1 manages an event-specific data record for each event, which characterizes the respective event.
  • an 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.
  • the planning system 1 has a calendar module 12.
  • time data 120 are stored for an event.
  • the calendar module also serves for temporal organization and visualization of the events.
  • the planning system 1 includes an 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.
  • FIG. 1 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.
  • 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.
  • the action pattern contains temporal conditions relative to the time at which the respective event should take place.
  • the action pattern may indicate, for example, that the ticket sale 6 weeks before the date of the event should begin.
  • the action patterns in the system can be preset or adapted by a user.
  • 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.
  • 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.
  • control center 26 can be informed at this time, for example, authorities and public Public transport about the planned event.
  • a concert should be held.
  • 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.
  • 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 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
  • 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.
  • commands to synchronize event record fields may be as follows:
  • 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.
  • 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.
  • 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.
  • step 311 in which an event-specific data record is created and stored in one
  • step 321 the planning system 1 sends a message (such as an e-mail) to an event manager.
  • step 322 the planning system 1 sends a message to a promoter.
  • 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.
  • an action pattern for the cancellation of an event with a binding event status is described below.
  • 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.
  • 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
  • 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.
  • 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.
  • the service provider 26 sends a corresponding command to the planning system 1, whereupon this deletes the event-specific data record.
  • 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.
  • the action pattern of the third embodiment is executed to first clear the event to be changed.
  • the action pattern from the second embodiment is executed to re-create the event in the changed form.
  • 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.
  • line 51 may include an identifier for the currently displayed or edited action pattern.
  • Line 52 may be titled Action pattern are occupied.
  • 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 ⁇ .
  • line 55 may contain comments on the respective action pattern.
  • 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.
  • 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

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé pour coordonner des systèmes décentralisés pour gérer des événements, selon lequel des données temporelles et des modèles d'action pour la planification et la réalisation d'un événement sont mémorisés de manière électronique dans un système de planification. Les données temporelles et les modèles d'action permettent de coordonner des opérations de processus pour planifier et réaliser un événement dans les systèmes décentralisés, des ordres parmi un ensemble d'ordres prédéterminé étant échangés entre le système de planification et les systèmes décentralisés par l'intermédiaire d'une interface homogène.
PCT/EP2006/065116 2005-08-17 2006-08-07 Procede pour coordonner des systemes decentralises pour gerer des evenements Ceased WO2007020207A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200510038911 DE102005038911A1 (de) 2005-08-17 2005-08-17 Verfahren zur Koordinierung dezentraler Systeme für ein Eventmanagement
DE102005038911.2 2005-08-17

Publications (1)

Publication Number Publication Date
WO2007020207A1 true WO2007020207A1 (fr) 2007-02-22

Family

ID=37025257

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/065116 Ceased WO2007020207A1 (fr) 2005-08-17 2006-08-07 Procede pour coordonner des systemes decentralises pour gerer des evenements

Country Status (2)

Country Link
DE (1) DE102005038911A1 (fr)
WO (1) WO2007020207A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19948028A1 (de) * 1998-11-20 2000-05-31 Ibm Verfahren und System zum Optimieren des Anforderungsschickens in Workflow Management Systemen
US20030084016A1 (en) * 2001-10-26 2003-05-01 Resultmaker A/S Method for generating a workflow on a computer, and a computer system adapted for performing the method
WO2004102431A1 (fr) * 2003-05-16 2004-11-25 Crux Cybernetics Pty Ltd Systeme de programmation d'au moins une tache possedant une pluralite d'activites a realiser par au moins un utilisateur du systeme
WO2005067614A2 (fr) * 2004-01-07 2005-07-28 Maxspeed Systeme et procede de gestion de participation

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1716509A4 (fr) * 2004-01-21 2009-07-22 Rnc Global Projects Procede et systeme de gestion de projet

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19948028A1 (de) * 1998-11-20 2000-05-31 Ibm Verfahren und System zum Optimieren des Anforderungsschickens in Workflow Management Systemen
US20030084016A1 (en) * 2001-10-26 2003-05-01 Resultmaker A/S Method for generating a workflow on a computer, and a computer system adapted for performing the method
WO2004102431A1 (fr) * 2003-05-16 2004-11-25 Crux Cybernetics Pty Ltd Systeme de programmation d'au moins une tache possedant une pluralite d'activites a realiser par au moins un utilisateur du systeme
WO2005067614A2 (fr) * 2004-01-07 2005-07-28 Maxspeed Systeme et procede de gestion de participation

Also Published As

Publication number Publication date
DE102005038911A1 (de) 2007-02-22

Similar Documents

Publication Publication Date Title
DE3788212T2 (de) Verfahren zur elektronischen Kalendererstellung zur Verwendung in einem Datenverarbeitungssystem.
DE3855555T2 (de) Verfahren zur Förderung einer Antwort auf einer elektronischen Konferenzeinladung in einem wechselwirkenden System mit mehreren Terminals, das elektronische Kalender benützt
DE3788210T2 (de) Verfahren, um Vermerke auf elektronischen Kalenderkopien in Datenverarbeitungssystemen automatisch in Einklang zu bringen.
DE102006021830B4 (de) System und Verfahren zur zeitgesteuerten Programmausführung
WO2015007700A1 (fr) Robot agenda
WO2007020207A1 (fr) Procede pour coordonner des systemes decentralises pour gerer des evenements
DE19546223A1 (de) Verfahren und Managementsystem zum Management von räumlich getrennten Objekten
DE19911699A1 (de) Verfahren zur Überwachung, Steuerung und/oder Optimierung von Prozeß- und/oder Arbeitsprojektplänen
DE102018121566B4 (de) Computer-implementiertes Verfahren zum Durchführen einer Konferenz in einem virtuellen Konferenzraum und Kollaborations- und Konversationsplattform
DE112021001504T5 (de) Vorrichtung zum Austausch von Nachrichten, und Verfahren zum Austausch von Nachrichten
EP1675045A1 (fr) Echange de données de description entre des projets à l'aide d'interfaces inter-projets
DE102021127367A1 (de) System und Verfahren zur Handhabung von personenbezogenen Dienstleistungen, insbesondere Reservierungssystem
DE202024101821U1 (de) Vorrichtung zur Verteilung und Wiedergabe von akustischen und/oder visuellen Signalen über ein Datennetzwerk in zumindest einem Aktionsteam von datentechnisch vernetzten Benutzern
WO2000055773A2 (fr) Dispositif, procede et produit programme d'ordinateur destines au fonctionnement de processus d'affaires
EP4553729A1 (fr) Systemes et procedes de fourniture, de demande et de gestion numeriques de services personnels et de services associes
DE102005024191B4 (de) Verfahren zum Betreiben eines Steuerungssystems insbesondere für Rundfunkanstalten
DE69910352T2 (de) Verfahren zum Kontrollieren der Arbeitsumgebung von Betriebsangestellten
DE69921861T2 (de) Strukturverwaltung und steuerungssystem
DE102018008132A1 (de) Verfahren zur Festlegung einer örtlichen und zeitlichen Zuordnung von Ressourcen und System zur Durchführung des Verfahrens
DE102006021048A1 (de) Verfahren, Vorrichtung und System zur konfigurationsabhängigen Steuerung der Informationsbereitstellung
EP4033753A1 (fr) Système de vidéoconférence et produit-programme informatique associé
DE10217512A1 (de) Verfahren zur Erstellung eines Schulungsplans zur Schulung von Anwendern in der 6-Sigma-Methode
EP3608854A1 (fr) Système et procédé pour essais numériques assistés par ordinateur
EP1762997A1 (fr) Configuration d'un panneau d'alarme
DE102005019869A1 (de) Verfahren zur Steuerung und Überwachung wenigstens eines Reparaturprozesses

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06778182

Country of ref document: EP

Kind code of ref document: A1