Time As Non-functional Requirement In Distributed Control .
INSTITUT FÜRAUTOMATISIERUNGSTECHNIKTime as non-functional requirement indistributed control systemsThomas Hadlich1, Stephan Höme1, Christian Diedrich1, Karin Eckert2, Timo Frank3,Alexander Fay2, Birgit Vogel-Heuser31Otto von Guericke UniversityMagdeburg, MagdeburgInstitute for u.deChristian.Diedrich@ovgu.de2Helmut Schmidt University, HamburgDepartment of Mechanical EngineeringInstitute of Automation hh.de3Technische Universität München,Institute of Automation and InformationSystems Technical ReportIFAT-LIA 1/201206. September 2012Universität MagdeburgFakultät für Elektrotechnik und InformationstechnikInstitut für AutomatisierungstechnikPostfach 4120, D-39016 MagdeburgGermany
AbstractWhen designing a distributed control system consisting ofheterogeneous components whose properties are usually notwell known, it is difficult or even impossible to use ananalytical approach to verify the fulfillment of allrequirements. In this contribution, it is shown (at the exampleof different implementation scenarios for a typical controlfunction) that detailed knowledge about the communicationsystem is required to reliably assess and compare differentdesigns of distributed systems with regard to a real-timecharacteristic. However, automation engineers typically canneither be expected to have such detailed knowledge about theinternal details of computing and communication, nor do theyhave the time to study different design alternatives in detail.This motivates further work of the authors towards betterengineering support for the design of distributed automationsystems, by providing helpful advice regarding designdecisions1. IntroductionModern trends in manufacturing are defined by masscustomization, small lot sizes (down to lot size one), whichrequire often changes in the physical layout of the plant,including enlargement and technical updates, high variabilityof product types, and a changing product portfolio during thelife cycle of the plant [3]. These trends imply more complexproducts which change faster and which need to be introducedfaster, and also a volatile production output and reducedinvestments in production systems [5].Different designs for manufacturing systems have beenproposed to fulfill these requirements, including HolonicManufacturing Systems (HMS) [3], [2], [5], BionicManufacturing Systems (BMS) [2], ReconfigurableManufacturing Systems (RMS) [2], and FlexibleManufacturing Systems (FMS) [2], [6]. Mobile softwareagents [3], [4] constitute a more recent proposal. Althoughthese system designs differ significantly in their approach toachieve the required flexibility in manufacturing, theircommon denominators are the spatial distribution of controlintelligence onto separate controllers or so-called “intelligentdevices” (henceforth called “nodes” in this manuscript), their(partial) autonomy regarding control decisions, and theircooperation, which requires means to communicate with eachother. This communication is implemented by means ofindustrial network infrastructure and industrial communicationprotocols. In a spatially distributed control system, it isnecessary to communicate the data flow as well as the controlflow between different parts of the control application. That iswhy the requirements of data flow and control flow define therequirements to the communication system such as jitter orend-to-end-delay time between sensory input and actuatoroutput.Usually, research projects regarding FMS, RMS, HMS ormulti-agent systems define certain properties of the nodesemployed, and use specially designed-for-purpose hardwarenodes and operating systems. Furthermore, in these researchprojects those who design the system structure are assumed tohave detailed knowledge regarding the properties and thefunctionality of the nodes. In contrast, the research workpresented in this manuscript targets at the engineering ofdistributed industrial control systems on the basis of existingcomponents and devices, which are already widely employedin industrial applications today, and aims at the support ofengineers who have only partial or superficial knowledgeabout the technical details of the nodes and the communicationtechnology employed (this holds for many practitioners). Thisincludes the aspects of distribution and communication.Contributions discussing industrial communication systemsoften focus either on the quality and stability of the controlloop and related non-functional requirements [8], [9], [7]. [8]discusses an evaluation of timing behavior on networkedcontrol systems with the focus on comparing different types ofcommunication behavior (time- / event-based). Thecontributions [9] and [7] emphasize the importance of timingon the function of complex automation systems, but focuseson a formal model for communication networks. The workpresented in this contribution targets automation engineeringrequirements, which must be satisfied in the process of theengineering process. For instance it should be possible toselect appropriate components and communication protocolsbased on the integration of the communication model intomodels of distributed applications.To show the necessity of a systematic method whichsupports the engineer during the design of distributed controlsystems, this paper discusses one non-functional requirement– timing – to show the tight relationship between designdecisions regarding distribution alternatives, communicationproperties, and timing results. Section 3 describes therefore anexample based on a thermo-hydraulic press. Two scenarios arederived from this example. In Section 4 measurements showthe need for support in the engineering of distributed controlsystems. At the end of this document we provide conclusions.Vogel-Heuser et al. [15] present a notation for modelingcommunication networks in automation engineeringintuitively and independently from suppliers. This notationprovides specification of automation architectures andimposition of real-time requirements the communicationnetwork has to meet. In this paper, the notation presented in[15] is used for the application example.In order to fulfill the functional and non-functionalrequirements the spatially distributed control nodes need tocommunicate with each other. The expansion of theautomation system leads to distributed control systems whichexecute automation tasks on different components and areconnected together by a communication system. However thephysical requirements, foremost the dynamics remain thesame. Therefore the total reaction time from sensor toactuators has to be the main focus. This contribution thereforedraws the focus from the definition and description of nonfunctional requirements (see 2) over the potential automationsystem architecture related to the communication system (see2) and at least to timeliness of the end-to-end-transmission2
time influenced by the communication. It does not covercontrol loop design and steady state investigations.APFB 2FB 1NodeApplication2. Distributed control ArchitectureWhen designing central or distributed systems it is a crucialsuccess factor to consider non-functional requirements. Somespecific non-functional requirements can be fulfilled moresuccessfully by distributed systems than by central systems,for instance reliability. Besides reliability, there are other nonfunctional requirements that are harder to fulfill withdistributed systems, e.g. time behavior. Time behaviordepends on response time and processing time as well as onthe transfer rate of the system of sensor - control - actuator. Indistributed systems the response time increases due to theadditional communication effort. In the design of distributedsystems it is important that the real-time conditions must bestrictly adhered.In order to model the real-time conditions of distributedsystems an integrated model of distributed application andcommunication has been presented in [12]. In the model thedistributed control application is split into several parts(function blocks (FBs)) (similar to [1]), which are executed inapplication processes. The intention of the model is not topropose a specific implementation but to show the distributednature of the application and the related communicationsystem elements. Kernel of the model for distributedautomation systems is the mapping of the application (and itsparts) to a set of communicating application processes (seeFigure 1).FB 2FB 1AIFB 3FB 4AOData flowCommunication networkNode 1APNode 2APNode 3APApplication ANode 4APControlled process/machinesFigure 1 – Mapping of the application parts to a set ofapplication processesEach FB or each FB network segment is allocated to thefunctional part of one application-process(AP) – see Figure 2.The AP model is based on the definitions in [HDE11], whichsuggests to integrate both the IEC 61158 AP model with thefunction block model as described in the following.APOAPOAPOASE 1ASE 2OSILayer 7AREPARFigure 2 – Model of an application processThe FB input and output data are mapped to the applicationprocess-objects (APOs) of the AP. The APO representing areal data object indicates mainly the data type, access rights(e.g. read/write or read only), communication related addressand the implementation specific access to the real data.The application-service-element-types (ASE types) whichare interacting with the APOs determine the allowed servicesfor accessing the APOs. For example: if FB input/output datacan be read or written, then the IO-data-ASE or the ParameterASE has access to the APO. If one data object is read only anda write service tries to write data to it, then the APO denies theaccess.The Parameter-ASE usually provides confirmed readservices and write services based on a client server model.These services need a connection oriented AR and provide theaccording role at the application-relationship-end-points(AREPs). The ARs determine data transport properties.Properties of an AR are for example cyclic/acyclic transport,buffered/queued services, client/server or rientedservices,transmission delay, etc. The ASE, APO and AR types togetherprovide the communication roles which are offered by theused communication system. The features of these elementshave strong influences to the fulfillment of the requirements.In one AP there can be multiple ASE instances from one ormore ASE types as well as multiple AR instances fromdifferent AR types. From the application point of view thismeans one AP can have communication relations to multipleother APs, which may use the same or differentcommunication services. One device can offer multiple APs.A summary of the consequences of this model are that the dataconnections between FBs at application level becomescommunication parameters which are conveyed overnetworks. The conveyance paths have extra properties whichare determined by communication system specific roles. Theseextra properties are coming up in distributed applications. Thecommunication systems details are defined in ASE, APO andAR type definitions.3
3. ApplicationExampletransmission timeforend-to-end-3.1. Introduction of the application exampleThe application example is part of a continuous thermohydraulic press for wood-based products. It is composed oftwo co-rotating conveyers which can be controlled separately.Between upper and lower conveyer the raw mixture iscompressed. The conveyers can be controlled in speed. Toavoid material defects by shearing stress the upper and lowerconveyer have to be synchronized regarding speed. To realizethe synchronization the two local conveyer control loops areintegrated in a “global” speed control loop. The differentcontrol loops are shown in Figure 3. The local control loopregulates the speed and the global control loop synchronizesthe speed of two conveyor belts.context in the system. In our example such a property is theend-to-end-transmission-time.The logical view provides the model as defined in [12].Such views are shown in Figure 5 and Figure 7. One canfollow the transmission paths from sensor to actuator, i.e. theend-to-end-path.3.3. Scenario 1 - Decentralized control hardware structureThe Decentral Scenario is characterized by the fact that thecontrol function, consisting of lower conveyer control, upperconveyer control and global control loops, is allocated to onenode and that the input and output devices communicate withthe control node via the communication system.Figure 4 – Decentral scenario: hardware structureFigure 3 – Local and global control loops ([14])The design goal is to implement a maximum speeddeviation of 0.5% at a conveyer speed of 2000 mm/s, thisrequires a response time smaller than 6ms. In the followingdiscussion we consider only input and output signals that areconnected via industrial communication. The complete controlapplication shown in Figure 3 may be allocated to one controlnode or to two control nodes. In the following somemeasurements are presented to show the importance of detailsin distribution and implementation to meet timingrequirements. The scenarios are introduced in the following.In such a scenario the signal and control value update cyclesof each individual device have to be considered. The inputvalue is acquired from the sensor and transported cyclically(input cycle) as APO from the sensor to the control node.SensorActorControl nodeAPAPAPOAPOAPO3.2. Introduction of the used schemes for the visualizationof the exampleIn this example we are considering the network topology,the used communication services as well as the timingbehavior of the involved system elements. Therefore theexample is depicted with appropriate diagrams for eachscenario.The network topology is shown in Figure 4, Figure 6 andFigure 11. The notation for these figures was introduced in[15]. The sensors and actuators are represented as I/O devicesand nodes in a PLC. Since the devices are connected usingEthernet, the switches are represented by four single smallrhombuses forming another large rhombus. The number ofports can be indicated in the lower rhombus. If a device hostsan Ethernet switch, this is indicated by integrating the switchsymbol into the device. Properties resulting from requirementsare placed in the scheme as additional box to indicate itsASE1FB 2AO 1APOAPOAPOASE1ASE2AREPSensordeviceAPFB 1AI 1APOAPOAPOASE2ASE1AREPAR 1ASE2AREPAR 2ActordeviceFigure 5 – Integrated model of application andcommunication for Decentral scenarioFrom the sensor the value is transported via the industrialcommunication system to the control node. This transportoccurs cyclically or acyclically depending on the type of theapplication relationship (AR type) between control applicationand input device (AR 1 in Figure 5). The control applicationtakes over the value. Then the control application processesthe input values and calculates the output values. The output4
values then are transported via the communication system(AR 2 in Figure 5) to the output device. The value then istransferred over the APO to the actuator application(cyclically).3.4. Scenario 2 - Distributed control hardware structureIf the control function is shared between two control nodes,for instance if lower conveyer control is executed on Node1and upper conveyer control and global control loops areexecuted on Node2, then the input device communicates withone control node (Node 1) and the output devicecommunicates with another control node (Node 2). Node 1and Node 2 communicate with each other in order toimplement the shared control function.Figure 6 – Distributed Scenario: hardware structureIn such a scenario the same transport delays have to beconsidered like in the scenario with one control node.Additionally the transport between the control nodes (Node 1and Node2) (AR 3) and the additional processing in Node 2has to be considered.SensorActorControl Node 1APAPAI 1APFB 1APOAPOAPOASE1FB 2APFB 1APOAPOAPOASE2ASE1AREPSensordeviceControl Node 2AO 1APOAPOAPOASE2ASE1AREPAR 1FB 2APOAPOAPOASE2AREPAR 3ASE1ASE2AREPAR 2ActordeviceFigure 7 – Integrated model of application andcommunication for Distributed ScenarioThe signals must pass the communication stacks of twocontrol nodes. This certainly introduces additional delay. Onthe other hand, the processing effort in Node1 may bereduced, because some functions are moved to Node2 (seeFigure 7). In the following section we research how theproperties of the application relationships (AR 1, AR 2 andAR 3) may influence this delay.4. Measurementstimeofend-to-end-transmission-In order to underline the influence of AR properties the endto-end-transmission-time was measured for followingarrangements: Decentral Scenario (1 input, 1 control node, 1 output) see Measurement 1 (see 4.1). Distributed Scenario (1 input, 2 control nodes, 1 output),witho Measurement 2(see 4.2): AR between the control nodesis based on a proprietary PLC-to-PLC protocol(connectionless, buffered, acyclic used by ParameterASE, Client/Server)o Measurement 3 (see 4.3): AR between the controlnodes is based on same protocol like thecommunication with the IOs, (connection-oriented,buffered, cyclic used by I/O data ASE, Client/Server)o Measurement 4 (see 4.4): AR between all elements isbased on same protocol but uses isochronousmechanism for communication between control nodesand the IOs, (connection-oriented, buffered used bycyclic, synchronous, I/O data ASE, Client/Server)In all measurements an analogue input and an analogueoutput device was used. The analogue input was triggeredwith a step signal and the time was measured until the samesignal was send out at the output device. The ‘processing’ inthe control node was reduced to assigning the input value tothe output value.The estimated precision of the time measurements is 1 µs.4.1. Measurement 1Measurement 1 serves as a reference allowing to comparethe results for a single controller with the results measured fora distributed control system (measurements 2 to 4).Communication for AR 1 and AR 2 is based on IOapplication relationship (8.3.10.2.2 in [13]), this AR is using munication relationship, which is characterized er/consumer.Figure 8 shows the transmission time observed over aduration of approximately 3 hours. When observing the endto-end-transmission-time, it is possible to observe 2 cycles inthe moving average of the transmission time. The major cycleis about 8000 seconds long. During this cycle the mediumtransmission time is changing slowly from about 5,5milliseconds to about 4 milliseconds, then the meantransmission time jumps back to around 5,5 milliseconds. Theminor cycle is about 125 seconds long, where the mediumtransmission time is changing within a range of 700microseconds.5
End‐to‐end‐transmission‐time:Mean value: 4625µs; Minimal value: 2210µs;Maximal value: 7022µs; Standard deviation: 842µsFigure 8 –Decentral scenario: end-to-end-transmissiontimeThese 2 cycles are caused by slips in the different clockcycles of the system. The major cycle most likely is caused bythe slip of the cycle of the output device in regard to the cycleof the input device. The cycles of the devices are out of syncin the beginning, because of the slip the cycles reach a goodsync at about 7000 seconds and then loose the sync again. Theminor cycle in the mean transmission time most likely iscaused by slips in other cycles (e.g. the communication cycle).All other measurements are based on the distributedscenario (two control nodes).4.2. Measurement 2In measurement 2 the same ASEs are used forcommunication of the IO data (AR 1 and AR 2), but thecommunication between the control nodes (AR 3) is based ona proprietary Ethernet-based protocol (Controller-ControllerAR). This protocol is transported on the same Ethernet as theIO communication, which may lead to additional delays in theproprietary protocol, because it has a lower priority as the IOcommunication and less bandwidth is allocated for thisprotocol.Figure 9 shows the transmission time observed over aduration of approximately 1,5 hours. In this measurement nocycles are recognizable. The variation in the transmission timeis caused mainly by the proprietary non-deterministicEthernet-protocol used in the communication between thecontrol nodes.End‐to‐end‐transmission‐time:Mean value: 10259µs; Minimal value: 4962µs;Maximal value: 16632µs; Standard deviation: 2180µsFigure 9 – Distributed Scenario:Proprietary PLC-to-PLC protocol4.3. Measurement 3In this measurement the communication between the controlnodes (AR 3) is based on the same IO AR like thecommunication to the IO devices (AR 1 and AR 2). One ofthe controllers acts as producer and the other as consumer ofthe transmitted value.End‐to‐end‐transmission‐time:Mean value: 5749µs; Minimal value: 2682µs;Maximal value: 8866µs; Standard deviation: 1003µsFigure 10 – Distributed Scenario: IO protocolFigure 10 shows the transmission time observed over aduration of approximately 1,5 hours. It is possible to recognizemultiple cycles in the transmission time. Compared tomeasurement 1 it is recognizable that not only two cycles havemajor influence on the transmission time, but multiple cyclesare out of sync. Compared to measurement 2 the variation ofthe transmission time has been reduced. The absolute end-toend-transmission-time has not yet reached the same quality asin using one control node.4.4. Measurement 4In this measurement the communication between thecontrollers is based on the same IO AR like thecommunication to the IO devices. One of the controllers actsas producer and the other as consumer of the transmitted6
value. The communication between controllers and the IOs issynchronized (isochronous ASEs).Because of the synchronized communication it was notpossible to use an unmanaged switch in the hardware setup.That is why the structure of the communication system had tobe changed to a line structure (see Figure 11).Node1PLCNode2TEH2PLCTEH2 In measurement 4 the average time for speed control cycleis approximately 3,6ms with a range from 1,8ms to 5,2ms.This meets the requirements because the averagetransmission time and the jitter is small enough. In measurements 1, 3 and 4 it is possible to observefrequency beats, which are the result of an interference ofcycles with different frequencies. These frequency beatscan be explained by the various cycles ofsoftware/hardware components in the communicationchain, but are subject of ongoing research.5. o-endAActordeviceFigure 11 – Distributed Scenario: Distributed controlloop with line structureMeasurement in this communication structure results inthe measurements shown in Figure 12.End‐to‐end‐transmission‐time:Mean value: 3608µs; Minimal value: 1758µs;Maximal value: 5124µs; Standard deviation: 651µsFigure 12 - Distributed Scenario: Isochronous protocolFigure 12 shows the transmission time observed over aduration of approximately 1,5 hours. The variation in thetransmission time has been strongly reduced. Actually thismeasurement shows a better behavior than measurement 1. Inmeasurement 1 the main source for variation was the slip inthe IO cycle (2 ms), while in this measurement the controlnodes are synchronized with the respective input or output.4.5. Discussion of the measurement resultsThere are strong differences in the end-to-end-transmissiontime for different AR types. The properties of the AR typesinfluence the result even if there is the same distributedstructure.The consequences for our example introduced in 3.1 are: Measurements 1-3 show that the respective networksolutions do not meet the requirements. In all solution thejitter is too large. In measurement 2 and 3 the averagetransmission time is too large.In this paper we show, that the selection of the used ARtypes and related communication services has significantinfluence on the quality of the automation solution. If theproperties of the chosen AR and communication services arenot considered, the quality of the automation solution degradeswith distributed control. But choosing the correct AR andcommunication services allows implementation of distributedcontrols at a quality similar or even better than a un-optimizedcentral control. On the other hand, it cannot be expected that adeveloper of control applications understands such details ofcommunication services,Further research of the authors will focus on developingsuitable methods to support less experienced engineers in theirchoices to meet non-functional requirements when designingdistributed control systems.Such a method shall able to: capture functional and non-functional requirements for thedistributed production system and for the controlapplication and maintain these requirements during thedesign flow, support a stepwise design flow, with design stages fromfunctional design to implementation (see [11]), identify the characteristics of the system under design at allstages of the design, use the characteristics of the system under design tosupport the engineers in their design decisions, and provide suggestions for solving design steps (see [10]).AcknowledgementThe work presented in this contribution is funded by theGerman Research foundation (DFG) under project FAVA.References[1] Christensen, J. H.: “HOLONIC MANUFACTURINGSYSTEMS: Initial Architecture and Standards Directions,”in First European Conference on Holonic ManufacturingSystems, Hannover, 1994.[2] Leitão, P.: Self-Organization in Manufacturing Systems:Challenges and Opportunities. In (IEEE Hrsg.): SecondIEEE International Conference on Self-Adaptive and SelfOrganizing Systems Workshops, 2008; p. 174–179.7
[3] Lüder, A. et al.: Distributed Automation: PABADIS versus[15] Vogel-Heuser, B. et al.: Modeling network architectureHMS. In IEEE Transactions on Industrial Informatics,2005, 1; p. 31–38.[4] Lepuschitz, W. et al.: Toward Self-Reconfiguration ofManufacturing Systems Using Automation Agents. InIEEE Transactions on Systems, Man, and Cybernetics, PartC (Applications and Reviews), 2011, 41; p. 52–69.[5] McFarlane, D. C.; Bussmann, S.: Developments in HolonicProduction Planning and Control. In Int. Journal ofProduction Planning and Control, 2000, 11; p. 522–536.[6] Herrero-Perez, D.; Martinez-Barbera, H.: ModelingDistributed Transportation Systems Composed of FlexibleAutomated Guided Vehicles in Flexible ManufacturingSystems. In IEEE Transactions on Industrial Informatics,2010, 6; p. 166–180.[7] Ghanaim, A.; Borges, G. A.; Frey, G.: Estimating Delaysin Networked Control Systems Using Colored Petri Netsand Markov Chain Models. In Proceedings of the 14thIEEE International Conference on Emerging Technologiesand Factory Automation (ETFA 2009), Palma de Mallorca,Spain, Sept. 2009.[8] Greifeneder, J.; Frey, G.: Reactivity Analysis of differentNetworked Automation System Architectures. InProceedings of the 13th IEEE International Conference onEmerging Technologies and Factory Automation (ETFA2008), Hamburg, Germany, pp. 1031-1038, Sept. 2008[9] Greifeneder, J.; Liu, L.; Frey, G.: Comparing Simulativeand Formal Methods for the Analysis of Response Timesin Networked Automation Systems, In Proceedings of the17th IFAC World Congress, pp. 5113-5118, Seoul,Südkorea, July 2008[10] Eckert, K.; Hadlich, T.; Frank, T. ; Fay, A. ; Diedrich, C.;Vogel-Heuser, B.: Design Patterns for DistributedAutomation Systems with Consideration of NonFunctional Requirements, ETFA 2012, Krakow, 2012[11] Frank, T.; Hadlich, T.; Eckert, K.; Diedrich, C.; VogelHeuser, B.; Fay, A.: Erweiterung des V-Modells für denEntwurf von verteilten Automatisierungssystemen. In:Ulrich Jumar, Eckehard Schnieder und Christian Diedrich(Hg.): EKA 2012. Magdeburg, 2012[12] Hadlich, T. et al.: Common communication model fordistributed automation systems. In (IEEE Hrsg.): INDIN2011. IEEE 9th International Conference on IndustrialInformatics, Caparica, Lisbon, Portugal, 26-29 July 2011,2011.[13] IEC: IEC 61158-500: Industrial communication networks– Fieldbus specifications. IEC, Genf, 2009.[14] Riefenstahl,U.: Regelverfahren,Bewegungssteuerung ; mit 9 Tabellen und 70 Beispielen.Teubner, Wiesbaden, 2006. p. 407and time behavior of Distributed Control Systems inindustrial plant automation: IECON 2011. 37th AnnualConference of the IEEE Industrial Electronics Society,2011.8
In the design of distributed systems it is important that the real-time conditions must be strictly adhered. In order to model the real-time conditions of distributed systems an integrated model of distributed application and communication has been presented in [12]. In the model the distributed control application is split into several parts
What are Non-functional Requirements? Functional vs. Non-Functional – Functional requirements describe what the system should do functions that can be captured in use cases behaviours that can be analyzed by drawing sequence diagrams, statecharts, etc. and probably trace to individual chunks of a program – Non-functional .
requirement and irrigation requirement of mustard, is 309 mm and 224 mm. respectively. By using the software a farmer of this zone can find out the water requirement and irrigation requirement by giving the crop name according to their season and duration of crop. Keywords: Crop water requirement, Irrigation Requirement, mustard.
Numeric Functional Programming Functional Data Structures Outline 1 Stuff We Covered Last Time Data Types Multi-precision Verification Array Operations Automatic Differentiation Functional Metaprogramming with Templates 2 Numeric Functional Programming Advanced Functional Programming with Templates Functional Data Structures Sparse Data Structures
4 Rig Veda I Praise Agni, the Chosen Mediator, the Shining One, the Minister, the summoner, who most grants ecstasy. Yajur Veda i̱ṣe tvo̱rje tv ā̍ vā̱yava̍s sthop ā̱yava̍s stha d e̱vo v a̍s savi̱tā prārpa̍yat u̱śreṣṭha̍tam āya̱
functional requirements). C.3.3 NON-FUNCTIONAL REQUIREMENTS. # Type Requirement SI Comments 1 Policy Compliance Work produced under this contract sha ll conform to the Smithsonian’s Technology Reference Model (TRM), SD-940-01. 2 Hosting Content to be hosted outside exhibition space must be hosted on SI’s centrally .
Using functional anal-ysis (Rudin, 1991), observational unit is treated as an element in a function and functional analysis concepts such as operator theory are used. In stochastic process methodology, each functional sample unit is considered as a realization from a random process. This work belongs to the functional analysis methodology. To predict infinite dimensional responses from .
AQAP-2110 (Edition 3) 3.0 Composition of requirements in AQAP 2110 3.1 Composition 3.1.1 A requirement in this publication is composed as follows: a. A title. b. A NATO requirement or an ISO requirement. Each ISO-requirement may have one or more NATO supplements. The supplements are grouped under the ISO-requirement.
Correction In the 12th Code Update Phase 2, we removed the requirement for park acreage as the requirement has now been met. Phase 2 should have also removed the SDP requirement in section 155.0253 and make the open space requirement be the same as citywide zoning. Remove the requirement for the SDP and make the open
