CZ2001395A3 - Způsob komunikace - Google Patents

Description

Způsob komunikace j

Oblast techniky

Vynález se týká způsobu komunikace k používání ve spojení s decentralizovaným sběrnícovým systémem., použitelným při automatizování technických procesů, ke kterému je připojeno několik účastníků komunikace, mezi nimi alespoň dva Master jakož i alespoň jeden Slavě, přičemž každý Master je přiřazen právě jednomu Mastersystému, přičemž Mastersystém nemá žádnou fyzikální odpovědnost, nýbrž pouze stanovuje možnost popř. nemožnost určitých komunikačních vztahů mezi účastníky komunikace, připojených ke sběrnicovému systému, přičemž alespoň Slavě rozpoznává každý telegram, předávaný po sběrnici a vyhodnocuje alespoň určitá data hlavičky telegramu a při shodě se zápisy, uloženými ve filtrační tabulce, dává data telegramu k dispozici své aplikaci.

Dosavadní stav techniky

Způsob komunikace popř. výměny dat, který zlepšuje komunikaci mezi účastníky, připojenými na sběrnici, je např. takzvaný příčný provoz, u kterého jsou např. přímo vyměnitelná data mezi takzvanými pasivními komunikačními stanicemi, v dalším Slaves, ačkoliv podle komunikačního protokolu, definovaného pro sběrnici, se nenechá vytvořit Žádný přímý komunikační vztah mezi takovými pasivními účastníky komunikace, a komunikace se dosud musela vždy uskutečňovat při vřazení takzvaného aktivního účastníka komunikace, v dalším Master, přičemž se mezi prvním pasivním účastníkem komunikace a takovým Master etabluje komunikační vztah a na

Master se převáděj! data, načež Master vytváří komunikační

9 »9	9 9	99	• 9 «
· ·	9	• 9 9	9 9 ·
99 9 9	•	9 9 99 9	9 9 ·
• 9 99 9 99	9 • 9	• 9 ··	9 9· 9· ··

vztah k druhému pasivnímu účastníku komunikace a data se tím konečně dostávají k druhému pasivnímu účastníku komunikace, vlastnímu příjemci.

Aktivní účastník komunikace, komunikace ve sběrnicovém systému,

Master, je účastník který může samostatně zahájit proces komunikace, naproti čemuž komunikace. Slavě, je účastník komunikace, pasivní účastník který, aby dodal data na sběrnici, potřebuje stále stimul zvenčí, např.

požadavek na spojení od Master.

Úkol předloženého vynálezu spočívá v tom, ještě optimálněji zkonstruovat při využití možností příčného provozu komunikaci ve sběrnicovém systému a mezi účastníky komunikace, připojenými na sběrnícový systém.

Podstata vynálezu

Úkol ee řeší způsobem komunikace k používání ve spojení s decentralizovaným sběrnicovým systémem, použitelným při automatizování technických procesů, ke kterému je připojeno několik účastníků komunikace, mezi nimi alespoň dva Master jakož i alespoň jeden Slavě, přičemž každý Master je přiřazen právě jednomu MastersyBtému, přičemž Mastersystém nemá žádnou fyzikální odpovědnost, nýbrž pouze stanovuje možnost popř. nemožnost určitých komunikačních vztahů mezi účastníky komunikace, připojených ke sběrnicovému systému, přičemž alespoň Slavě rozpoznává každý telegram, předávaný po sběrnici a vyhodnocuje alespoň určitá data hlavičky telegramu a při shodě se zápisy, uloženými ve filtrační tabulce, dává data telegramu k dispozici své aplikaci, jehož podstatou je, že přenos dat k Slavě prvního Mastersystému, vycházeje od Master vzdáleného Mastersystému, se uskutečňuje tím, že data hlavičky telegramu jsou vhodná, procházet filtrační tabulkou Slavě.

Přednostní provedení způsobu komunikace podle vynálezu spočívá v tom, že telegram, poslaný od Master se pro Slavě, alespoň vzhledem k hlavičce telegramu, neodlišuje od telegramu

účastníka	komunikace	stejného	Master	systému, poslaného
v rámci tzv	. příčného provozu.
Takové	provedení	se nechá	dále	ještě	rozšířit. Že
telegram	poslaný od	Master	se interní	identifikací

identifikuje jakó Response, takže se telegram pro Slavě systému Master, přenášený od Master systému Master, znázorňuje jako telegram příčného provozu, který se může spustit pomocí stimulu vlastního Master.

Přehled obrázků na výkresech

Další znaky, přednosti a možnosti použití vynálezu vyplývají z vedlejších nároků, z následujícího popisu příkladného provedení, podle obrázků a z vlastních obrázků. Všechny popisované a/nebo v obrázcích znázorněné znaky přitom tvoří pro sebe nebo v libovolné kombinaci předmět předloženého vynálezu nezávisle na jeho shrnutí v nárocích nebo jejich zpětném působení.

Přitom ukazují:

obr. 1: jednoduchou topologii sběrnice, obr. 2: identifikaci Mastersystémů, etablovaných na sběrnici, a obr. 3a, 3b, 4a, 4b: strukturu telegramu a strukturu filtrační tabulky v rámci příčného provozu.

Příklady provedení vynálezu

- ‘i Obr. 1 ukazuje topologii sběrnice se sběrnícovým systémem Bas účastníky komunikace, připojenými na sběrnicový systém B> přičemž jako účastníci komunikace jsou exemplárně znázorněni dva Master Ml, M2 a tři Slaves SI? S2, £2- Na sběrnicový systém B se může samozřejmě připojovat více než Master popř. Slaves, znázorněné na obr. 1.

U již známého možnosti jsou popsány příčného provozu, jehož přednosti a v ještě nezveřejněné evropské patentové

Přihlášce 97102093.8 (datum přihlášky10. 02.

97), se nechá komunikační vztah etablovat na ten způsob, že od jednoho aktivního účastníka komunikace, např.

Master

Ml. se posílá požadavek na spojení na alespoň jeden ze Slaves, např. na

Slavě SI.

Slavě SI reaguje, přičemž požadovaná data klade na způsob telegramu na sběrnici B- Data, kladená na sběrnici, přitom mají např. v hlavičce telegramu identifikaci, která vykazuje Slavě SI jako odesílatele a vykazuje další identifikaci, např. Master Ml jako příjemce. Další účastníci komunikace, připojení na sběrnicový systém, zejména Slaves £2? S3. naslouchají provozu na Bběrnici B á registrují přitom zejména telegram od Slavě SI na Master Ml. Aby se mohli účastnit příčného provozu, mají účastnici komunikace filtrační tabulku, ve které je uloženo, které telegramy, běžící po sběrnici, má registrovat účastník příčného provozu, i když nejsou vzhledem k cílové adrese přímo směrovány na tohoto účastníka. Když tedy pro Slavě S3 je v jeho filtrační tabulce uložen zápis ve tvaru odesílatel: SI. příjemce: Ml . přejímá Slavě S3 telegramy s touto identifikací a dává je k dispozici svým aplikacím. Tímto způsobem se šetří cesta přes Master Ml, neboť data, která pomocí příčného provozu přistála přímo u Slavě B, by se jinak musela předávat od Slavě SI na Master Ml a od tohoto na Slavě S3.

U alternativního způsobu příčného provozu se od Master, např. opět od Ml. posílá požadavek na spojení na minimálně

		— —	• • · e • • ···	♦* ·· .··. « 9 · * · « · · · ♦ ·»· A * « ··· • · · ·· ·· ··	* v · ·· • · · • · · · • Λ · ·· ···
jeden ze Slavě	, např. opět Slavě S1,	načež Slavě S1 reaguje,
přičemž klade	požadovaná	data na	sběrnici a	tentokrát
s identifikací	, která sice	identifikuje	Slavě S1	ještě jako
odesílatele,	jako příjemce	, má ale	identifikaci, která
způsobuje, že	se telegram	směřuje	na	všechny	zúčastněné

úCastníky komunikace. Takové vysílání se také označuje jako Publishing; v dalším se tedy vždy, když odesílatel klade na sběrnici telegram, který je směřován na všechny¹¹, označuje tento jako Publishing. Všichni účastníci komunikace, kteří přijímají telegram, publikovaný od Slavě £1, vyhodnocují přijímaná data podle již popsané, speciálně pro příslušného účastníka komunikace projektované, filtrační tabulky a dávají je popřípadě k dispozici jejich příslušné aplikaci. Filtrační tabulka jako taková odpovídá přitom v podstatě již popsané filtrační tabulce, přičemž rozdíl spočívá v tom, že se kontrolují už ne jednoznačně směřovaná vysílání, např.

vycháze je od Slavě £1, směřováno na Master

Ml, nýbrž že se kontroluj 1 publikovaná vyBÍláni, která jsou podle identifikace na všechny a dále podle identifikace původu identifikovatelná jako Publishing.

Filtrační tabulka se tím teoreticky nechá redukovat na identifikaci původu (také když může být prakticky úplně upraveno dodatečné zahrnutí

Service Access Point také ještě do filtrování), protože identifikace cíle je přece pro každé

Publishing identická. Textově formulováno, taková filtrační tabulka způsobuje, že pro každého pasivního účastníka komunikace je domluveno, že se přijímají a vyhodnocují

Publishings určitých jiných Slaves. Podle příkladu by se tedy mohlo udávat, že pomocí Slavě S3 se přijímají a vyhodnocují Publishings SlaveB S1 a £2, Že pomocí účastníka S2 komunikace se přijímají a vyhodnocují Publishings účastníků S1 a £3 komunikace a pomocí účastníka S1 se přijímají a vyhodnocují Publishing účastníků S2 a S3 komunikace.

φφφ · · ·· · · * · · φ · · · · · ·· · • ·«· · ♦ · ·♦* · · · · • φ · · · · · · φ·· φ· ·· ·· ·· ·♦·

Mezi příslušnými účastníky komunikace a tím zejména mezi aktivními účastníky komunikace a mezi pasivními účastníky komunikace, těmto přiřazeným, existuje vztah, které vyplývá z projektování. Tento vztah se v dalším označuje jako Mastersystém, protože na projektovaném vztahu je vždy zúčastněn alespoň jeden Master.

Podle obr. 2 jsou na sběrnicovém systému £ etablovány tři Mastersystémy MS1, MS2, MS3, přičemž Mastersystém MS1 je tvořen z Master Ml a Slavě SI a S2, analogicky Mastersystém MS2 zahrnuje účastníky M2. 53 komunikace a Mastersystém MS3 účastníka komunikace M3.

Komunikační vztahy, vycházeje od účastníka prvního Mastersystému, např. MS1, s účastníkem druhého Mastersystému, např. MS2, nejeou upraveny podle normy EN 50170, část II, brané zásadně za základ. Toto je na jedné straně podmíněno tím, když pomocí projektování např. prvního Mastersystému MS1 nejsou známé účastnické adresy příslušníků Mastersystému ΜΞ2 a následovně nejsou použitelné také u procesu komunikace, vycházeje od příslušníka prvního Mastersystému MS1. Projektovaný komunikační vztah mezi Master Mastersystému a Slavě, tomuto přiřazeným, dále způsobuje, že příjemce zprávy od vzdáleného Mastersystému rozpoznává, že tato zpráva nepatří ke komunikačnímu vztahu, projektovanému pro Mastersystém. To vede k tomu. Že přijatá zpráva se odmítá a tím se neregistruje popř. nevy hodnocuj e.

Tímto příčným provozem je ostatně možný komunikační vztah mezi Slavě různých Mastersystémů, přičemž např. master Ml Mastersystému MS1 vysílá Reguest, tedy požadavek na spojení, na Slavě £2., přiřazený Mastersystému MS1. načež tento publikuje svá data, což vede k tomu, že všichni účastnici komunikace, připojení ke sběrnicovému systému a tím např, i účastnici komunikace Mastersystému MS2 mohou těmto datům /

*

•		*«
• •	··· 9 « «·	• · • · ·♦	« ·· • ··	• · · • « ··	♦ ·

naslouchat na sběrnicí.

Pasivní účastník komunikace, např. Slavě £3., který jako všichni účastníci komunikace naslouchá i tomuto Publishing Slavě S2, může vyhodnotit data a rozpoznává podle filtrační tabulky, projektované pro tohoto Slavě S3. zda má přijatá data dávat k dispozici své aplikaci. Tak je příčným provozem již možná komunikace od jednoho Mastersystému k jinému Mastersystému, Samozřejmě je příčným provozem možná před jakož i poté komunikace mezi účastníky komunikace stejného Mastersystému, kteří spolu normálně nemohou komunikovat, tedy např. mezi dvěma pasivními účastníky komunikace stejného Mastersystému.

Proti tomu není dosud možná komunikace mezi Master prvního Mastersystému a účastníkem komunikace dalšího Mastersystému. Dále bylo již nahoře vysvětleno, že např. přímý komunikační vztah mezi Master M3 Mastersystému MS3 a Slavě S2 Mastersystému MS1 např. ztroskotá na tom, že příjemce zprávy od vzdáleného Mastersystému rozpoznává, že tato zpráva nepatří ke komunikačním vztahům, projektovaným pro vlastní Mastersystém, takže se zpráva odmítá.

Aby mohl Master M3 Mastersystému MS3 komunikovat s účastníkem komunikace Mastersystému MS1. např. se Slavě S1, musí data, která je třeba vysílat, přivádět na sběrnici ve speciálním formátu, přičemž se zejména předpona přenášeného telegramu, takzvané návěstí (header) telegramu, vyznačuje položkami, které mohou procházet filtrační tabulkou pasivního účastníka S1 komunikace. Telegram, poslaný od Master M3» má tím pro příjemce, pro účastníka S1 komunikace minimálně s ohledem na návěstí (header) ten vzhled, jako když by v rámci příčného provozu byl poslán od jiného účastníka komunikace, aktivního nebo pasivního účastníka komunikace.

• 99	to* *·	>·
9 9 ·	• 9 · ♦	•		··
• ···	to · · to to to	* to	*
• ·	toto ·	•	•
• to toto	·· «*	« ·		« to

Vynálezem se stává propustnou o sobě uzavřená struktura jednotlivých Mastersystémů pro telegramy od účastníků komunikace prvního Mastersystému na účastníky komunikace jiného Mastersystému.

Toto se způsobí tím, že když např, Master M3 chce na Slav© S2 přenášet data, generuje se k tomu telegram, který se vyznačuje tím, že jako cílová adresa se zanáší na všechny a jako zdrojová adresa se zanáší adresa odesílatele, v tomto případě tedy adresa Master M3. Slavě S2 rozpoznává telegram, přijatý od Master M3 jako telegram ve struktuře, kterou by akceptoval v rámci příčného provozu.

Alternativně může být upraveno, že účastník S2 komunikace telegram, přenášený od Master M3» akceptuje jako platný telegram v rámci příčného provozu jenom tehdy, když se telegram identifikuje pomocí interní identifikace jako Response, takže se telegram, přenášený od Master M3 Mastersystému MS3 pro Slavě S2 Mastersystému MS1. znázorňuje jako telegram v rámci příčného provozu, který může být spuštěn stimulem, např. vlastního Master Ml.

Na obrázcích 3a, 3b, popř. 4a, 4b jsou znázorněné záznamy zejména v návěstí (header) TH telegramu a data filtrační tabulky

El, která mu odpovídají. Podle obr. 3a zahrnuje telegram

T datový člen β a hlavičkový člen, návěstí TH telegramu. Návěstí (header) TH telegramu zahrnuje přinejmenším pozice k zanesení zdrojové adresy QA jakož i cílové adresy ZA.

Cílová adresa ZA označuje příjemce telegramu, zdrojová adresa

Q& označuje odesílatele telegramu. Dále jsou označeny pozice, které označují telegram jako požadavek na spojení nebo Reguest

REQ. nebo jako odpověď na požadavek na spojení, jako Response

RES. Ohledně označení jako Request REQ popř. Response RES může být upraveno. Že v návěstí (header) telegramu jsou upraveny dva oddělené zápisy, přičemž např. zápiB jedničky na příslušné

•	··	··	··	··
• • • ·*	·♦· · • ·«	9 · • · ··	♦ ·· « •	• · • · ·*	• ·

pozici označuje telegram jako Request, přičemž by se se potom musela analogicky jiná pozice přirozeně obsadit nulou. Alternativně může být také upraveno, že v návěstí (header) telegramu je upravena jenom jedna pozice, u které první zápis označuje telegram jako Request a druhý zápis, od něho odlišný, označuje telegram jako Response.

Obr. 3b ukazuje filtrační tabulku FT. ve které se nechají zapisovat zdrojové a cílové adresy, které k sobě právě patří, přičemž zápiB zdrojové adresy a cílové adresy každého přijatého telegramu se porovnává s příslušnými zápisy filtrační tabulky. Pokud se zjistí shoda, jedná se o telegram, který dává účastník komunikace k dispozici svým aplikacím.

Telegram 1 podle obr. 4a se odlišuje od telegramu X obr. 3a tím, že není udána Žádná explicitní cílová adresa. Bez explicitní cílové adresy se telegram směruje quasi na všechny. Protože informace o cílové adrese už není obsažena v telegramu X, redukuje se filtrační tabulka podle obr. 4b příslušně na data ohledně zdrojové adresy. Mělo by se ale poukázat na to, že když se tabulka podle obr. 3b popř. obr. 4b redukuje právě na zápis ohledně čísla stanice, představuje tato informace minimum. Podle provedení je proto upraveno, že tabulka zahrnuje vždy přinejmenším informace ohledně čísla stanice - k filtrování přijatých dat s ohledem na zdrojovou adresu - jakož i dále zdrojového SAP - k filtrování s ohledem na SAP, použitý při odesílání příchozích dat.

Pokud je upraveno, jak je posáno výše, že telegram se akceptuje jako platný telegram v rámci příčného provozu jenom tehdy, když se telegram pomocí interní identifikace identifikuje jako Response, není k přezkoušení této identifikace zapotřebí žádné filtrování na způsob filtrační tabulky, protože se jedná o jednoduché rozhodnutí když-tak, načež se telegram akceptuje, když Response-identifikace

-- * ·· »· ·· ·· · · · · · · ··· ····• ·· · · · ··· · • · · · · ··· ·· ·· ·· rozpoznává, Že se telegram odkazuje jinak.

Tím existuje tedy i pro aktivní účastníky komunikace vzdálených Mastersystémů možnost, posílat data na účastníky komunikace Mastersystémů, který není o sobě dosažitelný. Předpokladem pro to je, že tito účastníci komunikace mají filtrační tabulku na způsob, popsaný výše, a přinejmenším porovnávají návěstí (header) přenášeného telegramu s daty, zapsanými do filtrační tabulky podle projektování, a při shodě data příslušné vyhodnocují a dávají je k dispozici v příslušných aplikacích. Nový způsob komunikace se může např, přednostně používat při případech použití, u kterých jde o to, na všechny nebo na jednu skupinu systémových komponent působit zároveň nebo quasi zároveň, což např. je zejména tehdy ten případ, když se na obslužné stanici má vyvolat Not-vypnuto-funkce.

S ohledem na obr. 2 by se např. Not-vypnuto-f unkce kontrolovala od MaBter M3 a pokud βθ Not-vypnuto-funkce vyvolá, odesílá Master M$ telegram podle předloženého vynálezu na účastníky komunikace jiných Mastersystémů. Případ použití není samozřejmě omezen na Not-vypnuto-zpracování, nýbrž se nechá např. i přednostně použít při vyvolání synchronního stop nebo podobných akcí, které potřebují určitou synchronizaci, nebo u kterých jde o rychlou komunikaci na všechny účastníky komunikace, připojené na sběrnicový syBtém.

Claims (3)

1. Způsob komunikace k používání ve spojení s decentralizovaným sběrnicovým systémem (B), použitelným při automatizování technických procesů, ke kterému je připojeno několik účastníků komunikace, mezi nimi alespoň dva Master (Ml, M2) jakož i alespoň jeden Slavě (Sl), přičemž každý Master (Ml, M2) je přiřazen právě jednomu Mastersystému (MS1, MS2), přičemž Mastersystém (MS1, MS2) nemá žádnou fyzikální odpovědnost, nýbrž pouze stanovuje možnost popř. nemožnost určitých komunikačních vztahů mezi účastníky (Ml, M2, Sl) komunikace, připojených ke sběrnicovému systému (B) , přičemž alespoň Slavě (Sl) rozpoznává každý telegram, předávaný po sběrnici (B) a vyhodnocuje alespoň určitá data hlavičky telegramu a při shodě se zápisy, uloženými ve filtrační tabulce, dává data telegramu vyznačující se tím, prvního Mastersystému (MS1), vzdáleného Mastersystému (MS2), hlavičky telegramu jbou vhodná, Slavě (Sl).

   k dispozici své aplikaci. Že přenos dat k Slavě (Sl) vycházeje od Master (M2) se uskutečňuje tím, že data procházet filtrační tabulkou
2. 2. Způsob komunikace podle nároku 1, vyznačující se tím, že telegram, odeslaný od Master (M2), se pro Slavě (Sl) alespoň s ohledem na hlavičku telegramu neodlišuje od, posílaného v rámci tzv. příčného provozu, telegramu účastníka komunikace Btejného Mastersystému (MS1).
3. 3. ZpůBob komunikace podle nároku 2, vyznačující se tím, že telegram, posílaný od Master (M2), se identifikuje pomocí interní identifikace jako Response, takže se telegram, přenášený od Master (M3) Mastersystému (MS3), znázorňuje pro Slavě (Sl) Mastersystému (ΜΞ1) jako příčný provoz-telegram, který by se mohl vyvolat stimulem vlastního Master (Ml).

   X ώ ” • ·· · ·· • 9 9 ·♦ · 9 • • • 9 • a a • 9 · • • • · ♦ • a • ·· • · • 9*9 • * • a • · • 9 • • 9 • 9·· ·· ·· *· ·♦ ···