|
Requirements specification
Revision B - 14 MARCH 1996
|
| | Name | Position | E-mail address |
|---|
| Author(s): | Requirements team | | |
| Responsible: | Johan Sassner | Team Manager | pt93js@pt.hk-r.se |
| To: | Hans Ottosson
Anders Angelhag | Customer
Customer | hans.ottosson@sydkraft.se
anders.angelhag@telecom.sydkraft.se |
| Cc: | SAIDA
Fredrik Ygge
Peter Molin | SAIDA
Fredrik Ygge
Peter Molin | saida@pt.hk-r.se
fredrik.ygge@ide.hk-r.se
peter.molin@ide.hk-r.se |
1 Introduction
1.1 Purpose
The power market is evolving in such a way that power suppliers will be competing much more intensely for customers. In order to be competitive as a power supplier you have to be able to offer both present and potential customers extra services. Sydkraft has appreciated this situation and is currently researching different ways to achieve this.
The potential services do not only include selling cheaper power at certain periods, but also possibilities to supervise and monitor the power consumption. Customers will get the possibility to buy power at a lower price if they, for instance, can accept having their heater turned off during consumption peaks. Ultimately this will lead to reduced expenses for Sydkraft and their customers.
Sydkraft also wants to let their customers control and supervise their domestic appliances externally, e.g. via Internet with the use of tools like WWW browsers and E-mail. Of course, Sydkraft is also interested in controlling and supervising their power grid in a more flexible and inexpensive way.
SAIDA will aim at helping Sydkraft implementing these features.
1.2 System overview
Figure [1-1] describes the realationship between the system and its intended users. Usage can be said to be either from the appliction side or from the management/control side.
System overview
1.3 Detailed view
In figure [1-2] the CCN is described in some more detail. Everything included in the grey area (the four interfaces, the service applications and the LAN component layer) will be the result when the project is completed.
The CCN in detail
2 Interface requirements
2.1 Utility Interface (UTI)
2.1.1 Top level requirements
Functional requirements
F1 Service applications shall be able to export/import device data to standard applications. [F2,F3]
F2 Device data shall be both readable and writeable. [A3,A4]
Attribute requirements
A1 The UTI shall be highly available. [F4,A2,A5]
2.1.2 Bottom level requirements
Functional requirements
F3 Standard applications shall be able to use/update device data without the need of additional programming.
F4 Device data shall not be lost while other processes occupies the CCN.
Attribute requirements
The UTI shall...
A2 ... be able to manage user accesses concurrently.
A3 ... read device data quickly.
A4 ... write device data quickly.
A5 ... respond quickly to requests.
| AttrNr | Description | Scale | Worst |
|---|
| A1 | Availability | Percent of the time the UTI is available | 98 % |
| A2 | Request throughput | Percent of users getting the requested data per hour | 80% |
| A3 | Transfer rate in the CCN | Bytes per second | 10 Kb/s |
| A4 | Transfer rate in the CCN | Bytes per second | 10 Kb/s |
| A5 | Response time (local/remote) | Seconds | 1 s / 5 s |
2.2 Global Communication Interface (GCI)
2.2.1 Top level requirements
Functional requirements
F5 Device data shall be accessible via WWW. [A6,A7]
F6 It shall be possible for the CCN to receive e-mail from both a node and from the global system. [A9]
F7 The CCN shall be able to send e-mail to both a node (if the node is capable to receive an e-mail) and to the global system. [F8,F9]
F8 It shall be possible to monitor the behaviour of a node via e-mail.
F9 It shall be possible to control the behaviour of a node via e-mail.
2.2.2 Bottom level requirements
Attribute requirements
A6 Several users shall be able to access device data via WWW concurrently. [A8]
A7 Device data shall be highly available via WWW.
A8 The CCN shall respond quickly to user requests via WWW.
A9 The CCN shall be able to handle several incoming e-mails concurrently from several nodes.
| AttrNr | Description | Scale | Worst |
|---|
| A6 | Request throughput | Percent of users getting the requested data per hour | 80% |
| A7 | Availability | Percent of the time the GCI is available | 98 % |
| A8 | Response time (local/remote) | Seconds | 1 s / 5 s |
| A9 | Concurrency | Number of concurrently incoming e-mails managed by the CCN | 10 |
2.3 LAN Developer's Interface (LDI)
2.3.1 Top level requirements
Functional requirements
It shall be possible to...
F10 ... manage NeuronC programs in a node from remote. [F15,F16,F17,F18]
F11 ... control NeuronC programs in a node from remote. [F19,F20]
F12 ... configure the LAN structure dynamically. [F21,F22,F23]
F13 ... monitor all messages sent over the LAN.
F14 ... browse requested messages sent over the LAN.
2.3.2 Bottom level requirements
Functional requirements
It shall be possible to...
F15 ... receive NeuronC programs on the CCN.
F16 ... compile NeuronC programs on the CCN.
F17 ... install NeuronC programs in a node.
F18 ... remove NeuronC programs from a node.
F19 ... start NeuronC programs in a node. [A10]
F20 ... debug NeuronC programs in a node.
F21 ... add a new node to the LAN.
F22 ... remove a node from the LAN.
F23 ... bind addresses in the LAN.
Attribute requirements
A10 The CCN shall respond quickly to start requests.
| AttrNr | Description | Scale | Worst |
|---|
| A10 | The delay introduced by the CCN | Seconds | 3 s |
2.4 Service Applications Interface (SAI)
2.4.1 Top level requirements
Functional requirements
It shall be possible...
F24 ... for a user to do the same operations remotely as he/she can do locally, except operations requiring physical interaction, e.g. changing disk. [A15]
F25 ... to manage the service applications in the CCN through the service interface. [F28,F29,F30]
F26 ... to control the service applications in the CCN through the service interface. [F31,F32,F33]
F27 Service applications shall be able to run concurrently considering priorities.
Attribute requirements
A11 The SAI shall be highly available. [A14]
2.4.2 Bottom level requirements
Functional requirements
It shall be possible...
F28 ... to download service applications to the CCN.
F29 ... to install service applications in the CCN. [A12]
F30 ... to remove service applications from the CCN. [A13]
F31 ... to start a service application in the CCN.
F32 ... to stop a service application in the CCN.
F33 ... to debug a service application in the CCN.
Attribute requirements
It shall be possible...
A12 ... to install service applications in the CCN quickly.
A13 ... to remove service applications in the CCN quickly.
A14 ... to use the SAI concurrently.
A15 The SAI shall respond quickly to commands.
| AttrNr | Description | Scale | Worst |
|---|
| A11 | Availability | Percent of the time the SAI is available | 98 % |
| A12 | The delay introduced by the CCN | Seconds | 2 s |
| A13 | The delay introduced by the CCN | Seconds | 2 s |
| A14 | Request throughput | Percent of users getting the requested service per hour | 80% |
| A15 | Response time | Seconds | 2 s |
3 Application requirements
3.1 Service Applications (SEA)
Priority
3.1.1 Top level requirements
Functional requirements
F34 It shall be possible to set priority on the service applications in the CCN.
Alarm
3.1.2 Top level requirements
Functional requirements
F35 The CCN shall be able to export alarm signals from the nodes to the global system. [A16]
3.1.3 Bottom level requirements
Attribute requirements
A16 A service application shall export the alarm signal quickly.
| AttrNr | Description | Scale | Worst |
|---|
| A16 | The delay introduced by the CCN | Seconds | 1 s |
Logger
3.1.4 Top level requirements
Functional requirements
It shall be possible...
F36 .... for this application to log values from a node. [F37,F38]
3.1.5 Bottom level requirements
Functional requirements
It shall be possible...
F37 .... for service applications in the CCN to use the logged values.
F38 ... to log values in the CCN periodically and on change.
E-mail parser
3.1.6 Top level requirements
Functional requirements
It shall be possible...
F39 ... to parse an e-mail received from a node. [F41]
F40 ... to parse an e-mail received from the global system. [F42]
3.1.7 Bottom level requirements
Functional requirements
It shall be possible...
F41 ... to convert a predefined command to an e-mail.
F42 ... to convert an e-mail to a predefined command.
4 Appendix A
4.1 Terminology
4.1.1 Local Area Network (LAN)
The LAN consists of nodes, connected in a network, which in this project is the Lonworks architecture with Neuron chips.
4.1.2 Concentrator Communication Node (CCN)
The CCN connects the LAN to the rest of the world. Service applications run in the CCN and provides functionality for e.g. collecting data.
4.1.3 Node
A node is the smallest adressable part of a LonWorks network which e.g. handles monitoring and controling of electric machines. It communicates with the CCN and other nodes via the LAN.
4.1.4 Service Application (SEA)
A service application runs in the CCN and communicates through the Utility Interface, LAN Developer's Interface, Global Communication Interface and Service Applications Interface. It offers services like e-mail, collecting data from a node, monitoring network traffic etc.
4.1.5 Standard Application (STA)
A standard application is a program that can use device data via the CCN, e.g. Lotus 1-2-3, Quattro Pro and MS Excel.
4.1.6 World Wide Web (WWW)
WWW provides means to graphically display information over Internet using the HTML hypertext format.
4.1.7 E-mail
E-mail provides means to send messages over a network.
4.1.8 Global system
The external clients of the Utility Interface, LAN Developer's Interface, Global Communication Interface and Service Application Interface.
4.1.9 Device data (DD)
Device data represents the state of a node. This state could be represented in two ways (which type of state depends of the request): the logged data in the CCN and the current value of the node. This value could e.g. represent the temperature of a heater.
4.1.10 Utility Interface (UTI)
The interface towards the services provided by the CCN (service applications) and is used by Sydkraft's employees e.g. business administrators.
4.1.11 Global Communication Interface (GCI)
An interface which provides possibilities for the customer to monitor and control different electronic devices through e.g. WWW and e-mail.
4.1.12 LAN Developer's Interface (LDI)
An interface used by the node application developers.
4.1.13 Service Application Interface (SAI)
An interface used by the service application- and system developer.
4.1.14 Priority
If application A has higher priority than application B, application A will always execute before application B. It's more important e.g. for an alarm to execute than a logger.
4.1.15 Alarmsignal
An alarmsignal is a signal sent to the global system when an error has occured in a node.
4.1.16 Attribute terminology
4.1.16.1 AttrNr
A unique identifier.
4.1.16.2 Scale
A defined range of values within which the fulfilment of a requirement can be said to be at a discrete value.
4.1.16.3 Worst
The worst acceptable level of the attribute.
5 Appendix B
5.1 References
[Gilb 88] Gilb, T., "Principles of software engineering management" - 2.ed - Addison-Wesley Publishing Company, 1988.
[Ygge 96] Ygge, F., "PheasantPro Project Description, Version 1.0", - v1.0 - University of Karlskrona/Ronneby, 1996.
[QMG 96] Quality Management Group, "Requirements specification procedure", - pa2 - University of Karlskrona/Ronneby, 1996.
[SAIDA 96] The SAIDA project, "Why-Analysis", University of Karlskrona/Ronneby, 1996.
- Requirements specification
-
- 1 - Introduction
-
- 1.1 - Purpose
-
- 1.2 - System overview
-
- 1.3 - Detailed view
-
- 2 - Interface requirements
-
- 2.1 - Utility Interface (UTI)
-
- 2.1.1 - Top level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.1.2 - Bottom level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.2 - Global Communication Interface (GCI)
-
- 2.2.1 - Top level requirements
-
- Functional requirements
-
- 2.2.2 - Bottom level requirements
-
- Attribute requirements
-
- 2.3 - LAN Developer's Interface (LDI)
-
- 2.3.1 - Top level requirements
-
- Functional requirements
-
- 2.3.2 - Bottom level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.4 - Service Applications Interface (SAI)
-
- 2.4.1 - Top level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.4.2 - Bottom level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 3 - Application requirements
-
- 3.1 - Service Applications (SEA)
-
- Priority
-
- 3.1.1 - Top level requirements
-
- Functional requirements
-
- Alarm
-
- 3.1.2 - Top level requirements
-
- Functional requirements
-
- 3.1.3 - Bottom level requirements
-
- Attribute requirements
-
- Logger
-
- 3.1.4 - Top level requirements
-
- Functional requirements
-
- 3.1.5 - Bottom level requirements
-
- Functional requirements
-
- E-mail parser
-
- 3.1.6 - Top level requirements
-
- Functional requirements
-
- 3.1.7 - Bottom level requirements
-
- Functional requirements
-
- 4 - Appendix A
-
- 4.1 - Terminology
-
- 4.1.1 - Local Area Network (LAN)
-
- 4.1.2 - Concentrator Communication Node (CCN)
-
- 4.1.3 - Node
-
- 4.1.4 - Service Application (SEA)
-
- 4.1.5 - Standard Application (STA)
-
- 4.1.6 - World Wide Web (WWW)
-
- 4.1.7 - E-mail
-
- 4.1.8 - Global system
-
- 4.1.9 - Device data (DD)
-
- 4.1.10 - Utility Interface (UTI)
-
- 4.1.11 - Global Communication Interface (GCI)
-
- 4.1.12 - LAN Developer's Interface (LDI)
-
- 4.1.13 - Service Application Interface (SAI)
-
- 4.1.14 - Priority
-
- 4.1.15 - Alarmsignal
-
- 4.1.16 - Attribute terminology
-
- 4.1.16.1 - AttrNr
-
- 4.1.16.2 - Scale
-
- 4.1.16.3 - Worst
-
- 5 - Appendix B
-
- 5.1 - References
-
Info
Team
WebCam
Documents
Schedule
CustomerOnly
© 1996, The SAIDA Project