VDI 4451 Blatt 5-2005 Compatibility of Automated Guided Vehicle Systems (AGVS) - Interface between command initiator and AGVS control system.pdf

《VDI 4451 Blatt 5-2005 Compatibility of Automated Guided Vehicle Systems (AGVS) - Interface between command initiator and AGVS control system.pdf》由会员分享，可在线阅读，更多相关《VDI 4451 Blatt 5-2005 Compatibility of Automated Guided Vehicle Systems (AGVS) - Interface between command initiator and AGVS control system.pdf（6页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 53.060 VDI-RICHTLINIEN Oktober 2005October 2005VEREIN DEUTSCHER INGENIEURE Kompatibilitt von Fahrerlosen Transportsystemen (FTS) Schnittstelle zwischen Auftraggeber und FTS-Steuerung Compatibility of Automated Guided Vehicle Systems (AGVS) Interface between command initiator and AGVS control sys

2、tem VDI 4451 Blatt 5 / Part 5 Ausg. deutsch/englisch Issue German/English Die deutsche Version dieser Richtlinie ist verbindlich. No guarantee can be given with respect to the English transla-tion. The German version of this guideline shall be taken as authoritative. VDI-Gesellschaft Frdertechnik Ma

3、terialfluss Logistik Fachbereich B7 Fahrerlose Transportsysteme (FTS) VDI-Handbuch Materialfluss und Frdertechnik, Band 2 Frhere Ausgabe:12.94Entwurf, deutsch Former edition: 12/94 Draft, inGerman only Vervielfltigung auch fr innerbetriebliche Zwecke nicht gestattet / Reproduction even for internal

4、use not permittedZu beziehen durch / Available atBeuthVerlagGmbH, 10772 BerlinAlleRechtevorbehalten/ All rights reservedVerein Deutscher Ingenieure, Dsseldorf 2005 Inhalt Seite Contents Page 1 Begriffe und Definitionen. 3 1.1 Auftragbeber. 3 1.2 Transportauftrge . 3 1.3 FTS-Steuerung 3 1.4 Transport

5、auftragsverwaltung 3 1.5 Fahrauftrge 3 2 Schnittstellenkomponenten. 4 3 Schnittstellenprotokoll. 4 4 Informationsdaten 4 4.1 Telegrammarten 4 4.2 Standardaufbau Telegramm 5 Schrifttum 6 1 Terms and definitions.3 1.1 Command initiator 3 1.2 Transport commands.3 1.3 AGVS control system .3 1.4 Transpor

6、t command processor3 1.5 Driving commands3 2 Interface components.4 3 Interface protocol4 4 Information data4 4.1 Typs of telegram.4 4.2 Standard telegram structure 5 Bibliography.6 B55EB1B3E14C22109E918E8EA43EDB30F09DCCB7EF86D9NormCD - Stand 2012-08 2 VDI 4451 Blatt 5 / Part 5 Alle Rechte vorbehalt

7、en Verein Deutscher Ingenieure, Dsseldorf 2005 Bild 1. Allgemeine Darstellung einer FTS-Leitsteuerung Fig. 1. General representation of an AGVS guidance control system B55EB1B3E14C22109E918E8EA43EDB30F09DCCB7EF86D9NormCD - Stand 2012-08Alle Rechte vorbehalten Verein Deutscher Ingenieure, Dsseldorf 2

8、005 VDI 4451 Blatt 5 / Part 5 3 1 Begriffe und Definitionen 1.1 Auftraggeber Auftraggeber fr die FTS-Steuerung ist die Trans-portmitteldisposition, die Bestandteil der globalenMaterialflusssteuerung oder Fertigungssteuerung ist. Je nach gegebener Datenverarbeitungsstrukturkann die Transportmitteldis

9、position auf einen odermehrere Rechner verteilt sein. Die Transportmitteldisposition kann auch vomBediener bernommen werden. 1.2 Transportauftrge Transportauftrge sind das Produkt der Transport-mitteldisposition im Rahmen der globalenMaterialflusssteuerung oder Fertigungssteuerung.Ein Transportauftr

10、ag beginnt immer an einer Quel-le und endet an einer Senke. Anmerkung: Das Material muss dabei nicht unbedingt imphysischen Sinne aufgenommen oder abgegeben, sondern kann auch von einer Bearbeitungsstation zu einer anderen transportiert werden (fahrbare Werkbank, Flielinienbetrieb). 1.3 FTS-Steuerun

11、g Eine FTS-Steuerung umfasst alle Komponenten, die zum Betrieb der Auftragserfllung im Sinnedes Auftraggebers erforderlich sind. Anmerkung: Eine komplette FTS-Steuerung kann sowohl in einem Fahrzeug enthalten sein als auch auf mehrere Fahrzeu-ge, Informationskomponenten und Leitrechner verteilt sein

12、. 1.4 Transportauftragsverwaltung Die Transportauftragsverwaltung ist der Empfn-ger von Transportauftrgen, die vom Auftraggebererteilt werden. Anmerkung: Sie ist Bestandteil der FTS-Steuerung und hatunter anderem die Aufgabe, mit dem Auftraggeber zu korres-pondieren. 1.5 Fahrauftrge Fahrauftrge sind

13、 das Produkt der Fahrzeugdispo-sition in der FTS-Steuerung. Anmerkung: Fahrauftrge knnen z. B. Fahrten mit Last,Leerfahrten, Lastwechsel oder Batterieladefahrten beinhalten.1 Definitions of terms 1.1 Command initiator The command initiator of the AGVS control sys-tem is the transport medium provisio

14、n which is a component of the global materials handling control or process control system. Depending on the DP structure used, the transport medium provision may be on one computer or distributed among several. It is also possible, that the transport medium provi-sion is carried out by the user of t

15、he AGVS. 1.2 Transport commands Transport commands are initiated by the transport medium provision within the framework of the global materials handling control or process control system. A transport command starts at a source and ends at a sink. Note: The material need not necessarily be picked or

16、placed physically, but may also be transported from one processing station to another (mobile workbench, flow line production).1.3 AGVS control system An AGVS control system comprises all compo-nents required to execute the commands as recei-ved from the command initiator. Note: A complete AGVS cont

17、rol system may be one vehicle or distributed among several vehicles, information compo-nents, and transport master computers. 1.4 Transport command processor The transport command processor receives the transport commands from the command initiator.Note: It is a component of the AGVS control system,

18、 one of its tasks being to communicate with the command initiator.1.5 Driving commands Driving commands are initiated by the vehicle provision which is part of the AGVS control sys-tem. Note: Driving commands may include transport, idle return and battery-charging travels. B55EB1B3E14C22109E918E8EA4

19、3EDB30F09DCCB7EF86D9NormCD - Stand 2012-08 4 VDI 4451 Blatt 5 / Part 5 Alle Rechte vorbehalten Verein Deutscher Ingenieure, Dsseldorf 2005 2 Schnittstellenkomponenten Die Schnittstellenkomponenten richten sich imWesentlichen an der eingesetzten Rechnerumge-bung aus. Bedingt durch die rasante Entwick

20、lungim Rechnerumfeld hat sich bisher kein eindeutigerStandard durchgesetzt. Aktuell weit verbreitete Techniken sind u. a.: Ethernet RS 485 RS422 RS232 2 Interface components Interface components are essentially determined by the computer environment used. Owing to the fast pace of development in com

21、puter environments, no clear standard has yet emerged. Common technologies currently include: Ethernet RS 485 RS 422 RS 232 3 Schnittstellenprotokoll Schnittstellenprotokolle sind Vereinbarungen undVerfahren, um Nachrichten (Telegramme) sicherund fehlerfrei zu bertragen. Da sie in der Regelauf die v

22、erwendeten Schnittstellenhardware abge-stimmt sind, zeichnet sich auch hier kein eindeuti-ger Standard ab. Als aktuelle Lsungen knnen u. a. genanntwerden: TCP/IP (Sockets, ftp .) OPC Feldbusprotokolle (Profibus, Interbus-S .) Anmerkung: Anpassungen an proprietre Protokolle knnen mit dem Lieferanten

23、abgesprochen werden. 3 Interface protocol Interface protocols are conventions and procedures for transmitting messages (telegrams) reliably and accurately. As they are generally matched to the interface hardware used, there is no clear standard here either. Current methods include: TCP/IP (sockets,

24、ftp, ) OPC field bus protocols Note: Adoptions to proprietary protocols may be arranged with the supplier. 4 Informationsdaten Um die Portabilitt effektiv und die bertragungs-zeiten kurz zu halten, ist eine schmale“ Daten-kopplung (Telegrammart) mit hohem Freiheitsgrad(Telegramminhalt) bei gleichzei

25、tiger Normung(Telegrammaufbau) notwendig. Fr eine vollstndige, sichere Informationsbertra-gung reichen zwei Telegrammarten mit standardi-siertem Aufbau aus. Gegebenenfalls sind weitereTelegrammarten zur Synchronisation und zumDatenabgleich nach Systemausfall einzubeziehen.4.1 Telegrammarten Transpor

26、tauftrag Transportauftragsrckmeldung 4 Information data For the sake of efficient portability and short transmission times, a “narrow” data coupling (type of telegram) is required, providing a considerable degree of freedom (telegram content) combined with standardisation (telegram structure). Two t

27、ypes of telegram with a standardised structu-re are adequate for complete and reliable informa-tion transmission, but it may be necessary to inclu-de further types of telegram for the purpose of synchronisation and data matching after a system failure. 4.1 Types of telegram transport command transpo

28、rt command echo B55EB1B3E14C22109E918E8EA43EDB30F09DCCB7EF86D9NormCD - Stand 2012-08Alle Rechte vorbehalten Verein Deutscher Ingenieure, Dsseldorf 2005 VDI 4451 Blatt 5 / Part 5 5 4.2 Standardaufbau Telegramm Grund-Information muss enthalten sein Primre Information muss/kann enthalten sein Start-Ken

29、nung fr sekundre Information kann enthalten sein Sekundre Information kann enthalten sein Ende-Kennung Telegramm muss enthalten sein 4.2.1 Grund-Information Die Grund-Information ist in ihrem Aufbau beiallen Telegrammen gleich. Telegrammart Hier ist die Information hinterlegt, um welche Telegrammart

30、 es sich handelt (z. B. Transport-auftrag usw.) Auftragsnummer Eindeutige Zuordnung (z. B. lfd. Nr.) Status Enthlt einen der jeweiligen Telegrammart zu-geordneten Status. Die Statusliste knnte aus einem fest definierten Teil sowie einem frei definierbaren Teil bestehen (z. B. Prioritt 2, Stornieren

31、usw.) 4.2.2 Primre Informationen Primre Informationen werden bei der Tele-grammart Transportauftrag“ sowie bedingt bei derTelegrammart Transportauftragsrckmeldung“bentigt. Bei Transportauftrgen muss enthalten sein: Primr-Information Quelle (z. B. Bahnhof 17) Senke (z. B. Bahnhof 19) Bei Transportauf

32、tragsrckmeldungen kann enthal-ten sein: Primr-Information Fehlerstatus (z. B. Senke belegt) 4.2.3 Start-Kennung Sekundre Informationen“ Eine Start-Kennung Sekundre Information“ ist notwendig, wenn sekundre Informationen folgen.4.2.4 Sekundre Informationen Sekundre Informationen knnen bei der Tele-gr

33、ammart Transportauftrag“ sowie bei der Tele-4.2 Standard telegram structure Basic information mandatory Primary information mandatory/optional Begin-secondary-information flag optional Secondary information optional End-of-telegram flag mandatory 4.2.1 Basic information The basic information has the

34、 same structure for all telegrams. Type of telegram information about the type of telegram (e. g. transport command, etc.) Command number unique identifier (consecutive number) Status status relevant to the type of telegram con-cerned; the status list may consist of a specified part and a part to be

35、 defined arbitrarily (e. g. priority 2, cancel, etc.) 4.2.2 Primary information Primary information is required for the “transport command” type of telegram and, in some cases, for the “transport command echo” type of telegram. Mandatory for transport commands: Primary information Source (e. g. stat

36、ion 17) Sink (e. g. station 19) Optional for transport command echoes: Primary information error status (e. g. sink occupied) 4.2.3 Begin-secondary-information flag A begin-secondary-information flag is required when secondary information is to follow. 4.2.4 Secondary information For both “transport

37、 command” and “transport command echo” telegram types, secondary infor-B55EB1B3E14C22109E918E8EA43EDB30F09DCCB7EF86D9NormCD - Stand 2012-08 6 VDI 4451 Blatt 5 / Part 5 Alle Rechte vorbehalten Verein Deutscher Ingenieure, Dsseldorf 2005 grammart Transportauftragsrckmeldung“ an die primren Information

38、en nach eigener Definitionund Struktur angehngt werden. Dadurch bleibt dieFlexibilitt voll erhalten. Beispiele fr sekundre Informationen sind: bei Transportauftrgen“ Prioritt des Auftrags frhest mgliche Abholung sptest mgliche Anlieferung Aktionen an Quelle/Senke Hubhhen an Quelle/Senke Informatione

39、n ber die zu transportierende Last, wie Palettenbreite, Palettentyp, Ge-wicht, Barcode Fahrzeugnummer Fahrzeugtyp Datum/Uhrzeit zweite Quelle/Senke fr Fahrzeuge mit Platz fr zwei Lasten bei Transportauftragsrckmeldungen“ z. B. fr Zwischenmeldungen: Lastaufnahme durchgefhrt Auftrag in Bearbeitung 4.2

40、.5 Ende-Kennung Telegramm“ Durch diese Kennung wird der Abschluss des Telegramms eindeutig und allgemein angezeigt. mation with its own definition and structure can be appended to the primary information. Full flexibili-ty is thus retained. Examples for secondary information are: for “transport comm

41、and” priority of the command earliest possible collection latest possible delivery action at the source/sink height of lift at source/sink information about the transport load e. g. pallet width, pallet type, weight, barcode vehicle number type of vehicle date/time second source/sink for vehicles wi

42、th space for two loads for “transport command echo” e. g. for intermediate messages picking up executed order in progress 4.2.5 End-of-telegram flag This flag is a unique and general marker for the end of the telegram. Schrifttum/Bibliography VDI 2510 : 2005-10 Fahrerlose Transportsysteme (FTS) (Aut

43、omated Guided Vehicle Systems (AGVS). Berlin: Beuth Verlag VDI 4451 Blatt 2 : 2000-10 Kompatibilitt von Fahrerlosen Transportsystemen (FTS); Energieversorgung und Ladetech-nik (Compatibility of Automated Guided Vehicle Systems (AGVS); Power supply and charging). Berlin: Beuth Verlag VDI 4451 Blatt 3

44、 : 1998-03 Kompatibilitt von Fahrerlosen Transportsystemen (FTS); Fahr- und Lenkantrieb (Compatibi-lity of Automated Guided Vehicle Systems (AGVS); Driving and steering motors). Berlin: Beuth Verlag VDI 4451 Blatt 6 : 2003-01 Kompatibilitt von Fahrerlosen Transportsystemen (FTS); Sensorik fr Navigat

45、ion und Steue-rung (Compatibility of Automated Guided Vehicle Systems (AGVS); Sensor systems for navigation and control). Berlin: Beuth Verlag VDI 4451 Blatt 7 : 2005-10 Kompatibilitt von Fahrerlosen Transportsystemen (FTS); Leitsteuerung fr FTS (Compatibi-lity of Automated Guided Vehicle Systems (AGVS); AGVS guidance control system). Berlin: Beuth Verlag B55EB1B3E14C22109E918E8EA43EDB30F09DCCB7EF86D9NormCD - Stand 2012-08