SEMI E30-1000 GENERIC MODEL FOR COMMUNICATIONS AND CONTROL协议原版文件

PAGE

11

SEMIE30-1000©SEMI1992,2000

SEMIE30-1000©SEMI1992,2000

PAGE

10

SEMIE30-1000

GENERICMODELFORCOMMUNICATIONSANDCONTROLOFMANUFACTURINGEQUIPMENT(GEM)

ThisstandardwastechnicallyapprovedbytheGlobalInformation&ControlCommitteeandisthedirectresponsibilityoftheNorthAmericanInformation&ControlCommittee.CurrenteditionapprovedbytheNorthAmericanRegionalStandardsCommitteeonJuly14andAugust28,2000.Initiallyavailableat

August2000;tobepublishedOctober2000.Originallypublishedin1992;previouslypublishedJune2000.

CONTENTS

Introduction

RevisionHistory

Scope

Intent

Figure1.1,GEMScope

Overview

Figure1.2,GEMComponents

ApplicableDocuments

Definitions

StateModels

StateModelMethodology

CommunicationsStateModel

Figure3.0,ExampleEquipmentComponentOverview

Figure3.2.1,CommunicationsStateDiagram

Table3.2,CommunicationsStateTransitionTable

ControlStateModel

Figure3.3,ControlStateModel

Table3.3,CONTROLStateTransitionTable

EquipmentProcessingStates

Figure3.4,ProcessingStateDiagram

Table3.4,ProcessingStateTransitionTable

EquipmentCapabilitiesandScenarios

EstablishCommunications

DataCollection

Figure4.2.1,LimitCombinationIllustration:ControlApplication

Figure4.2.2,ElementsofOneLimit

Figure4.2.3,LimitStateModel

Table4.2,LimitStateTransitionTable

AlarmManagement

Figure4.3,StateDiagramforAlarmALIDnTable4.3.1,AlarmStateTransitionTableTable4.3.2

RemoteControl

EquipmentConstants

ProcessProgramManagement

MaterialMovement

EquipmentTerminalServices

ErrorMessages

Clock

Spooling

Figure4.11,SpoolingStateDiagram

Table4.11,SpoolingStateTransition

Control

DataItems

DataItemRestrictions

VariableItemList

CollectionEvents

Table6.1,GEMDefinedCollectionEvents

SECS-IIMessageSubset

STREAM1:EquipmentStatus

STREAM2:EquipmentControlandDiagnosticsSTREAM5:Exception(Alarm)ReportingSTREAM6:DataCollection

STREAM7:ProcessProgramLoadSTREAM9:SystemErrorsSTREAM10:TerminalServicesSTREAM14:ObjectServices

STREAM15:RecipeManagement

GEMCompliance

FundamentalGEMRequirements

Figure8.1,GEMRequirementsandCapabilities

Table8.1,FundamentalGEMRequirements

GEMCapabilities

Table8.2,SectionReferencesforGEMCapabilities

DefinitionofGEMCompliance

Documentation

Figure8.2,HostViewofGEM

Table8.3,GEMComplianceStatement

Table8.4,SMLNotation

ApplicationNotes

FactoryOperationalScript

AnytimeCapabilities

SystemInitializationandSynchronization

ProductionSet-Up

Processing

Post-Processing

EquipmentFrontPanel

DisplaysandIndicators

Switches/Buttons

ExamplesofEquipmentAlarms

TableA.3,AlarmExamplesPerEquipmentConfigura-tion

TraceDataCollectionExample

HarelNotation

FigureA.5.1,HarelStatechartSymbolsFigureA.5.2,ExampleofORSubstatesFigureA.5.3,ExampleofANDSubstates

StateDefinitions

TransitionTable

TableA.5,TransitionTableforMotorExample

ExampleControlModelApplication

ExamplesofLimitsMonitoring

Introduction

Examples

FigureA.7.1,ValveMonitoringExampleFigureA.7.2,EnvironmentMonitoringExampleFigureA.7.3,CalibrationCounterExample

RecipeParameterModificationforProcessandEquipmentControl

Introduction

EquipmentConstants

Example

FigureA.8.1,CMPSingleWafer“Polishing”SystemwithHostRecipeParameterModificationCapability

Index

SEMIE30-1000

GENERICMODELFORCOMMUNICATIONSANDCONTROLOFMANUFACTURINGEQUIPMENT(GEM)

ThisstandardwastechnicallyapprovedbytheGlobalInformation&ControlCommitteeandisthedirectresponsibilityoftheNorthAmericanInformation&ControlCommittee.CurrenteditionapprovedbytheNorthAmericanRegionalStandardsCommitteeonJuly14andAugust28,2000.Initiallyavailableat

August2000;tobepublishedOctober2000.Originallypublishedin1992;previouslypublishedJune2000.

Introduction

RevisionHistory—ThisisthefirstreleaseoftheGEMstandard.

Scope—ThescopeoftheGEMstandardislimitedtodefiningthebehaviorofsemiconductorequipmentasviewedthroughacommunicationslink.TheSEMIE5(SECS-II)standardprovidesthedefinitionofmessagesandrelateddataitemsexchangedbetweenhostandequipment.TheGEMstandarddefineswhichSECS-IImessagesshouldbeused,inwhatsituations,andwhattheresultingactivityshouldbe.Figure1.1illustratestherelationshipofGEM,SECS-IIandothercommunicationsalternatives.

TheGEMstandarddoesNOTattempttodefinethebehaviorofthehostcomputerinthecommunicationslink.ThehostcomputermayinitiateanyGEMmessagescenarioatanytimeandtheequipmentshallrespondasdescribedintheGEMstandard.WhenaGEMmessagescenarioisinitiatedbyeitherthehostorequipment,theequipmentshallbehaveinthemannerdescribedintheGEMstandardwhenthehostusestheappropriateGEMmessages.

Figure1.1GEMScope

Thecapabilitiesdescribedinthisstandardarespecificallydesignedtobeindependentoflower-level

communicationsprotocolsandconnectionschemes(e.g.,SECS-I,SMS,point-to-point,connection-orientedorconnectionless).Useofthosetypesofstandardsisnotrequiredorprecludedbythisstandard.

Thisstandarddoesnotpurporttoaddresssafetyissues,ifany,associatedwithitsuse.Itistheresponsibilityoftheusersofthisstandardtoestablishappropriatesafetyandhealthpracticesanddeterminetheapplicabilityofregulatorylimitationspriortouse.

Intent—GEMdefinesastandardimplementationofSECS-IIforallsemiconductormanufacturingequipment.TheGEMstandarddefinesacommonsetofequipmentbehaviorandcommunicationscapabilitiesthatprovidethefunctionalityandflexibilitytosupportthemanufacturingautomationprogramsofsemiconductordevicemanufacturers.EquipmentsuppliersmayprovideadditionalSECS-IIfunctionalitynotincludedinGEMaslongastheadditionalfunctionalitydoesnotconflictwithanyofthebehaviororcapabilitiesdefinedinGEM.SuchadditionsmayincludeSECS-IImessages,collectionevents,alarms,remotecommandcodes,processingstates,variabledataitems(datavalues,statusvaluesorequipmentconstants),orotherfunctionalitythatisuniquetoaclass(etchers,steppers,etc.)orspecificinstanceofequipment.

GEMisintendedtoproduceeconomicbenefitsforbothdevicemanufacturersandequipmentsuppliers.EquipmentsuppliersbenefitfromtheabilitytodevelopandmarketasingleSECS-IIinterfacethatsatisfiesmostcustomers.DevicemanufacturersbenefitfromtheincreasedfunctionalityandstandardizationoftheSECS-IIinterfaceacrossallmanufacturingequipment.Thisstandardizationreducesthecostofsoftwaredevelopmentforbothequipmentsuppliersanddevicemanufacturers.Byreducingcostsandincreasingfunctionality,devicemanufacturerscanautomatesemiconductorfactoriesmorequicklyandeffectively.TheflexibilityprovidedbytheGEMstandardalsoenablesdevicemanufacturerstoimplementuniqueautomationsolutionswithinacommonindustryframework.

TheGEMstandardisintendedtospecifythefollowing:

AmodelofthebehaviortobeexhibitedbysemiconductormanufacturingequipmentinaSECS-IIcommunicationenvironment,

Adescriptionofinformationandcontrolfunctionsneededinasemiconductormanufacturingenvironment,

AdefinitionofthebasicSECS-IIcommunicationscapabilitiesofsemiconductormanufacturingequipment,

AsingleconsistentmeansofaccomplishinganactionwhenSECS-IIprovidesmultiplepossiblemethods,and

Standardmessagedialoguesnecessarytoachieveusefulcommunicationscapabilities.

TheGEMstandardcontainstwotypesofrequirements:

fundamentalGEMrequirementsand

requirementsofadditionalGEMcapabilities.

ThefundamentalGEMrequirementsformthefoundationoftheGEMstandard.TheadditionalGEMcapabilitiesprovidefunctionalityrequiredforsometypesoffactoryautomationorfunctionalityapplicabletospecifictypesofequipment.AdetailedlistofthefundamentalGEMrequirementsandadditionalGEMcapabilitiescanbefoundinChapter8,GEMCompliance.Figure1.2illustratesthecomponentsoftheGEMstandard.

Figure1.2GEMComponents

EquipmentsuppliersshouldworkwiththeircustomerstodeterminewhichadditionalGEMcapabilitiesshouldbeimplementedforaspecifictypeofequipment.BecausethecapabilitiesdefinedintheGEMstandardwerespecificallydevelopedtomeetthefactoryautomationrequirementsofsemiconductormanufacturers,itisanticipatedthatmostdevicemanufacturerswillrequiremostoftheGEMcapabilitiesthatapplytoaparticulartypeofequipment.SomedevicemanufacturersmaynotrequirealltheGEMcapabilitiesduetodifferencesintheirfactoryautomationstrategies.

Overview—TheGEMstandardisdividedintosectionsasdescribedbelow.

Section1—Introduction

Thissectionprovidestherevisionhistory,scopeandintentoftheGEMstandard.Italsoprovidesanoverviewofthestructureofthedocumentandalistofrelateddocuments.

Section2—Definitions

Thissectionprovidesdefinitionsoftermsusedthroughoutthedocument.

Section3—StateModels

Thissectiondescribestheconventionsusedthroughoutthisdocumenttodepictstatemodels.Italsodescribesthebasicstatemodelsthatapplytoallsemiconductormanufacturingequipmentandthatpertaintomorethanasinglecapability.Statemodelsdescribethebehavioroftheequipmentfromahostperspective.

Section4—CapabilitiesandScenarios

Thissectionprovidesadetaileddescriptionofthecommunicationscapabilitiesdefinedforsemiconductormanufacturingequipment.Thedescriptionofeachcapabilityincludesthepurpose,definitions,requirements,andscenariosthatshallbesupported.

Section5—DataDefinitions

ThissectionprovidesareferencetotheDataItemDictionaryandVariableItemDictionaryfoundinSEMIStandardE5.ThefirstsubsectionshowsthosedataitemsfromSECS-IIwhichhavebeenrestrictedintheiruse(i.e.,allowedformats).ThesecondsubsectionlistsvariabledataitemsthatareavailabletothehostfordatacollectionandshowsanyrestrictionsontheirSECS-IIdefinitions.

Section6—CollectionEvents

Thissectionprovidesalistofrequiredcollectioneventsandtheirassociateddata.

Section7—SECSMessageSubset

ThissectionprovidesacompositelistoftheSECS-IImessagesrequiredtoimplementallcapabilitiesdefinedintheGEMstandard.

Section8—GEMCompliance

ThissectiondescribesthefundamentalGEMrequirementsandadditionalGEMcapabilitiesandprovidesreferencestoothersectionsofthestandardwheredetailedrequirementsarelocated.Thissectionalsodefinesstandardterminologyanddocumentationthatcanbeusedbyequipmentsuppliersanddevicemanufacturerstodescribecompliancewiththisstandard.

SectionA—ApplicationNotes

Thesesectionsprovideadditionalexplanatoryinformationandexamples.

SectionA.1—FactoryOperationalScript

ThissectionprovidesanoverviewofhowtherequiredSECScapabilitiesmaybeusedinthecontextofatypicalfactoryoperationsequence.Thissectionisorganizedaccordingtothesequenceinwhichactionsaretypicallyperformed.

SectionA.2—EquipmentFrontPanel

Thissectionprovidesguidanceinimplementingtherequiredfrontpanelbuttons,indicators,andswitchesasdefinedinthisdocument.Asummaryofthefrontpanelrequirementsisprovided.

SectionA.3—ExamplesofEquipmentAlarms

Thissectionprovidesexamplesofalarmsrelatedtovariousequipmentconfigurations.

SectionA.4—TraceDataCollectionExample

Thissectionprovidesanexampleoftraceinitializationbythehostandtheperiodictracedatamessagesthatmightbesentbytheequipment.

SectionA.5—HarelNotation

ThissectionexplainsDavidHarel’s“Statechart”notationthatisusedthroughoutthisdocumenttodepictstatemodels.

SectionA.6—ExampleControlModelApplication

Thissectionprovidesoneexampleofahost’sinteractionwithanequipment’scontrolmodel.

SectionA.7—ExamplesofLimitsMonitoring

Thissectioncontainsfourlimitsmonitoringexamplestohelpclarifytheuseoflimitsandtoillustratetypicalapplications.

ApplicableDocuments

SEMIStandards—ThefollowingSEMIstandardsarerelatedtotheGEMstandard.ThespecificportionsofthesestandardsreferencedbyGEMconstituteprovisionsoftheGEMstandard.

SEMIE4—SEMIEquipmentCommunicationsStandard1—MessageTransfer(SECS-I)

SEMIE5—SEMIEquipmentCommunicationsStandard2—MessageContent(SECS-II)

SEMIE13—StandardforSEMIEquipmentCommunicationStandardMessageService(SMS)

SEMIE23—SpecificationforCassetteTransferParallelI/OInterface

OtherReferences

Harel,D.,“Statecharts:AVisualFormalismforComplexSystems,”ScienceofComputerProgramming8(1987)231-2741.

NOTE1:Aslistedorrevised,alldocumentscitedshallbethelatestpublicationsofadoptedstandards.

Definitions

alarm—Analarmisrelatedtoanyabnormalsituationontheequipmentthatmayendangerpeople,equipment,ormaterialbeingprocessed.Suchabnormalsituationsaredefinedbytheequipmentmanufacturerbasedonphysicalsafetylimitations.Equipmentactivitiespotentiallyimpactedbythepresenceofanalarmshallbeinhibited.

Notethatexceedingcontrollimitsassociatedwithprocesstolerancedoesnotconstituteanalarmnordonormalequipmenteventssuchasthestartorcompletionofprocessing.

capabilities—Capabilitiesareoperationsperformedbysemiconductormanufacturingequipment.TheseoperationsareinitiatedthroughthecommunicationsinterfaceusingsequencesofSECS-IImessages(orscenarios).Anexampleofacapabilityisthesettingandclearingofalarms.

collectionevent—Acollectioneventisanevent(orgroupingofrelatedevents)ontheequipmentthatisconsideredtobesignificanttothehost.

communicationfailure—Acommunicationfailureissaidtooccurwhenanestablishedcommunicationslinkisbroken.Suchfailuresareprotocolspecific.Refer

1ElsevierScience,P.O.Box945,NewYork,NY10159-0945,

http://www.elvesier.nl/homepage/browse.htt

totheappropriateprotocolstandard(e.g.,SEMIE4orSEMIE37)foraprotocol-specificdefinitionofcommunicationfailure.

communicationfault—Acommunicationfaultoccurswhentheequipmentdoesnotreceiveanexpectedmessage,orwheneitheratransactiontimeroraconversationtimerexpires.

control—Tocontrolistoexercisedirectinginfluence.

equipmentmodel—Anequipmentmodelisadefinitionbasedoncapabilities,scenarios,andSECS-IImessagesthatmanufacturingequipmentshouldperformtosupportanautomatedmanufacturingenvironment.(SeealsoGenericEquipmentModel.)

event—Aneventisadetectableoccurrencesignificanttotheequipment.

GEMcompliance—Theterm“GEMCompliance”isdefinedwithrespecttoindividualGEMcapabilitiestoindicateadherencetotheGEMstandardforaspecificcapability.Section8includesmoredetailonGEMCompliance.

GenericEquipmentModel—TheGenericEquipmentModelisusedasareferencemodelforanytypeofequipment.Itcontainsfunctionalitythatcanapplytomostequipment,butdoesnotaddressuniquerequirementsofspecificequipment.

host—TheSEMIE4andE5standardsdefineHostas“theintelligentsystemthatcommunicateswiththeequipment.”

messagefault—Amessagefaultoccurswhentheequipmentreceivesamessagethatitcannotprocessbecauseofadefectinthemessage.

operationalscript—Anoperationalscriptisacollectionofscenariosarrangedinasequencetypicalofactualfactoryoperations.Examplesequencesaresysteminitializationpowerup,machinesetup,andprocessing.

operator—Ahumanwhooperatestheequipmenttoperformitsintendedfunction(e.g.,processing).Theoperatortypicallyinteractswiththeequipmentviatheequipmentsuppliedoperatorconsole.

processunit—Aprocessunitreferstothematerialthatistypicallyprocessedasaunitviasingleruncommand,processprogram,etc.Commonprocessunitsarewafers,cassettes,magazines,andboats.

processingcycle—Aprocessingcycleisasequencewhereinallofthematerialcontainedina

typicalprocessunitisprocessed.Thisisoftenusedasameasureofactionortime.

scenario—AscenarioisagroupofSECS-IImessagesarrangedinasequencetoperformacapability.Otherinformationmayalsobeincludedinascenarioforclarity.

SECS-I—SEMIEquipmentCommunicationsStandard1(SEMIE4).ThisstandardspecifiesamethodforamessagetransferprotocolwithelectricalsignallevelsbaseduponEIARS232-C.

SECS-II—SEMIEquipmentCommunicationsStandard2(SEMIE5).Thisstandardspecifiesagroupofmessagesandtherespectivesyntaxandsemanticsforthosemessagesrelatingtosemiconductormanufacturingequipmentcontrol.

SMS—SECSMessageService.AnalternativetoSECS-ItobeusedwhensendingSECS-IIformattedmessagesoveranetwork.

statemodel—AStateModelisacollectionofstatesandstatetransitionsthatcombinetodescribethebehaviorofasystem.Thismodelincludesdefinitionoftheconditionsthatdelineateastate,theactions/reactionspossiblewithinastate,theeventsthattriggertransitionstootherstates,andtheprocessoftransitioningbetweenstates.

systemdefault—Referstostate(s)intheequipmentbehavioralmodelthatareexpectedtobeactiveattheendofsysteminitialization.Italsoreferstothevalue(s)thatspecifiedequipmentvariablesareexpectedtocontainattheendofsysteminitialization.

systeminitialization—Theprocessthatanequipmentperformsatpower-up,systemactivation,and/orsystemreset.Thisprocessisexpectedtopreparetheequipmenttooperateproperlyandaccordingtotheequipmentbehavioralmodels.

user—Ahumanorhumanswhorepresentthefactoryandenforcethefactoryoperationmodel.Auserisconsideredtoberesponsibleformanysetupandconfigurationactivitiesthatcausetheequipmenttobestconformtofactoryoperationspractices.

3StateModels

Thefollowingsectionscontainstatemodelsforsemiconductormanufacturingequipment.Thesestatemodelsdescribethebehavioroftheequipmentfromahostperspectiveinacompactandeasytounderstandformat.Statemodelsfordifferentequipmentwillbeidenticalinsomeareas(e.g.,communications),butmayvaryinotherareas(e.g.,processing).Itisdesirabletodividetheequipmentintoparallelcomponentsthatcan

bemodeledseparatelyandthencombined.AnexampleofacomponentoverviewofanequipmentisprovidedasFigure3.0.

Equipmentmanufacturersmustdocumenttheoperation-albehavioroftheirequipmentusingstatemodelmeth-odology.StatemodelsarediscussedinSections3.1and

A.5andinareferencedarticle.Documentationofastatemodelshallincludethefollowingthreeelements:

Astatediagramshowingthepossiblestatesofthesystemorcomponentsofasystemandallofthepossibletransitionsfromonestatetoanother.Thestatesandtransitionsmusteachbelabeled.UseoftheHarelnotation(seeA.5)isrecommended.

Atransitiontablelistingeachtransition,thebeginningandendstates,whatstimulustriggersthetransition,andanyactionstakenasaresultofthetransition.

Adefinitionofeachstatespecifyingsystembehaviorwhenthatstateisactive.

ExamplesoftheaboveelementsareprovidedinSectionA.5.

Figure3.0

ExampleEquipmentComponentOverview

Thebenefitsofprovidingstatemodelsare:

Statemachinemodelsareausefulspecificationtool,

Ahostsystemcananticipatemachinebehaviorbaseduponthestatemodel,

End-usersandequipmentprogrammershaveacommondescriptionofmachinebehaviorfromwhichtowork,

“Legal”operationscanbedefinedpertainingtoanymachinestate,

Externaleventnotificationscanberelatedtointernalstatetransitions,

Externalcommandscanberelatedtostatetransitions,

Statemodelcomponentsdescribingdifferentaspectsofmachinecontrolcanberelatedtooneanother(example:processingstatemodelwithmaterialtransportstatemodel;processingstatemodelwithinternalmachinesafetysystems).

StateModelMethodology—Todocumenttheexpectedfunctionalityofthevariouscapabilitiesdescribedinthisdocument,the“Statechart”notationdevelopedbyDavidHarelhasbeenadopted.AnarticlebyHarelislistedinSection1.5andshouldbeconsidered“must”readingforafullunderstandingofthenotation.Theconventionusedinthisandfollowingsectionsistodescribethedynamicfunctionalityofacapabilitywiththreeitems:atextualdescriptionofeachstateorsubstatedefined,atablethatdescribesthepossibletransitionsfromonestatetoanother,andagraphicalfigurethatusesthesymbolsdefinedbyHareltoillustratetherelationshipsofthestatesandtransitions.Thecombinationoftheseitemsdefinethestatemodelforasystemorcomponent.AsummaryoftheHarelnotationandamoredetaileddescriptionofthetext,table,andfigureusedtodefinebehaviorwiththismethodologyiscontainedintheApplicationNoteA.5.

Thebasicunitofastatemodelisthestate.Astateisastaticsetofconditions.Iftheconditionsaremet,thestateiscurrent.Theseconditionsmightinvolvesensorreadings,switchpositions,timeofday,etc.Alsopartofastatedefinitionisadescriptionofreactionstospecificstimuli(e.g.,ifmessageSx,Fyisreceived,generatereplymessageSx,Fy+1).StimulimaybequitevariedbutforsemiconductorequipmentwouldincludereceivedSECSmessages,expiredtimers,operatorinputatanequipmentterminal,andchangesinsensorreadings.

Tohelpclarifytheinterpretationofthisdocumentandthestatemodelsdescribedherein,itisusefultodistin-guishbetweenastateandaneventandtherelationshipofonetotheother.Aneventisdynamicratherthanstatic.Itrepresentsachangeinconditions,ormorespecifically,theawarenessofsuchachange.Aneventmightinvolveasensorreadingexceedingalimit,aswitchchangingposition,oratimelimitexceeded.

Achangetoanewactivestate(statetransition)mustalwaysbepromptedbyachangeinconditions,andthusanevent.Inaddition,astatetransitionmayitselfbe

termedanevent.Infact,therearemanyeventsthatmayoccuronanequipment,soitisimportanttoclassifyeventsbasedonwhethertheycanbedetectedandwhethertheyareofinterest.Inthisdocument,thetermeventhasbeenmorenarrowlydefinedasadetectableoccurrencethatissignificanttotheequipment.

Afurthernarrowingofthedefinitionofeventisrepre-sentedbytheterm“collectionevent,”whichisanevent(orgroupofrelatedevents)ontheequipmentthatisconsideredsignificanttothehost.Itistheseeventsthat(ifenabled)arereportedtothehost.Bythisdefinition,thelistofcollectioneventsforanequipmentwouldtyp-icallybeonlyasubsetoftotalevents.Thestatemodelsinthisdocumentareintendedtobelimitedtothelevelofdetailinwhichthehostisinterested.Thus,allstatetransitionsdefinedinthisstandard,unlessotherwisespecified,shallcorrespondtocollectionevents.

CommunicationsStateModel—TheCommunicationsStateModeldefinesthebehavioroftheequipmentinrelationtotheexistenceorabsenceofacommunicationslinkwiththehost.Section4.1expandsonthissectionbydefiningtheEstablishCommunicationscapability.Thismodelpertainstoalogicalconnectionbetweenequipmentandhostratherthanaphysicalconnection.

Terminology—Thetermscommunicationfail-ure,connectiontransactionfailure,andcommunicationlinkaredefinedforusewithinthisdocumentonlyandshouldnotbeconfusedwiththesameorsimilartermsusedelsewhere.

SeeSEMIE4(SECS-I)orSEMIE37(HSMS)foraprotocolspecificdefinitionsofcommunicationsfailure.

Aconnectiontransactionfailureoccurswhenattemptingtoestablishcommunicationsandiscausedby

acommunicationfailure,

thefailuretoreceiveanS1,F14replywithinareplytimeoutlimit,or

receiptofS1,F14thathasbeenimproperlyformattedorwithCOMMACK2notsetto0.

Areplytimeoutperiodbeginsafterthesuccessfultransmissionofacompleteprimarymessageforwhichareplyisexpected.(SeeSEMIE4(SECS-I)

orSEMIE37(HSMS)foraprotocol-specificdefinitionofreplytimeout.)

AcommunicationlinkisestablishedfollowingthefirstsuccessfulcompletionofanyoneS1,F13/F14transactionwithanacknowledgementof“accept”.Theestablishmentofthislinkislogicalratherthanphysical.

Implementationsmayhavemechanismswhichallowoutgoingmessagestobestoredtemporarilypriortobeingsent.Thenounqueueisusedtocoversuchstoredmessages.Theyarequeuedwhenplacedwithinthequeueandaredequeuedbyremovingthemfromthisstorage.

Sendincludes“queuetosend”or“begintheprocessofattemptingtosend”amessage.Itdoesnotimplythesuccessfulcompletionofsendingamessage.

Thehostmayattempttoestablishcommunicationswithequipmentatanytimeduetotheinitializationofthehostorbyindependentdetectionofacommunicationsfailurebythehost.Thus,thehostmayinitiateanS1,F13/F14transactionatanytime.

CommDelayTimer—TheCommDelaytimerrepresentsaninternaltimerusedtomeasuretheintervalbetweenattemptstosendS1,F13.ThelengthofthisintervalisequaltothevalueintheEstablishCommuni-cationsTimeout.TheCommDelaytimerisnotdirectlyvisibletothehost.

EstablishCommunicationsTimeoutistheuser-configur-ableequipmentconstantthatdefinesthedelay,inseconds,betweenattemptstosendS1,F13.ThisvalueisusedtoinitializetheCommDelaytimer.

TheCommDelaytimerisinitializedtobegintiming.TheCommDelaytimerisinitializedonlywhenthestateWAITDELAYisentered.

TheCommDelaytimerisexpiredwhenit“timesout,”andthetimeremainingintheintervalbetweenattemptstosendiszero.WhenthetimerexpiresduringthestateWAITDELAY,ittriggersanewattempttosendS1,F13andthetransitiontothestateWAITCRA3.

Conventions

TheattempttosendS1,F13ismadeonlyupontransitintothestateWAITCRA.TheCommDelayTimershouldbesetto“expired”atthistime.

2EstablishCommunicationsAcknowledgeCode,definedinSection

4.1.SeetheSEMIE5StandardforfurtherdefinitionofthisDataItem.

CRAisthemnemonicdefinedforEstablishCommunicationsRequestAcknowledge(S1,F14).

TheCommDelaytimerisinitializedonlyupontransitint