revision of SECoP documentation

- created secop_v2017-09-14.rst, based on the GoogleDocs
  SECoP Preliminary V2016-11-30 (rc 2)
- this Document is supposed to contain the full SECoP standard
- created SECoP issues
- moved everything else to "outdated" (kept for reference)

Change-Id: I87d69d1846fc4ed55f1c78b22fd4650d8550152b
Reviewed-on: https://forge.frm2.tum.de/review/16573
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>

doc/source/protocol/issue_9.rst

@@ -0,0 +1,39 @@
+SECoP Issue 9: Module Meaning (under discussion)
+================================================
+
+meaning
+-------
+
+For the ECS an automatic detection of the main modules would be desirable.
+
+For example a SEC Node could tell which sensor would be the closest one to
+the sample, which should be registered in the ECS as the sample temperature.
+
+For this, a module property "meaning" is proposed. This can get one of the
+following values:
+
+* sample_temperature
+* magnetic_field
+
+importance
+----------
+
+But what to do, if several modules claim to be the sample temperature?
+There might be a SEC node controlling cryostat, which has a sample temperature sensor,
+but another SEC node controlling an insert with a sample sensor. As the insert
+is put into the cryostat, we declare the cryostat to have importance=1 and
+the insert an importance=2. To resolve the ambiguity, the ECS chooses the
+module with the highest importance to be labelled as the read sample temperature.
+
+Proposal:
+
+predefined importance:
+
+ * importance=1 for a device which can not be inserted or added to another one
+ * importance=2 for a device which can be inserted into an other one
+
+Higher values are to be used when an additional device may be inserted into an insert
+and the like.
+
+We should allow importance to be a floating point number, in case later a value
+between 1 and 2 has to be used.