DSfG - Archive / - Logbuch --- Frau Bremm

[Melanie Hermann]

Anmerkungen von Frau Bremm zu den Tests vom 09.04.2013/10.04.2013:

• 10.04.2013 07:53:46 beginnt das Timeout > Kein Extraeintrag in der DSfG bezüglich beginnendem Timeout (Alarm)
• 10.04.2013 11:32:16 endet das Timeout > Auch hier kein Extraeintrag in der DSfG bezüglich quittiertem Timeout (Alarm)
• Mittelwert um 12:00:00 Uhr wird als ungestört eingetragen, obwohl das Timeout bis 11:32:16 angedauert hat
• Status fehlt bei, als ungesört marktiertem, Mittelwerteintrag
• Timeout im DSfG-Logbuch wird als Ersatzwert gekennzeichnet -> falsch

[Melanie Hermann]

Weitere Anmerkungen von Frau Bremm bez. V.1.336-068 siehe Email vom 10.07.2013.

[Melanie Hermann]

TODO: -> DONE:

• Kal. kommt / geht hat keine sekundengenauen Zeitstempel in den DSfG-MW-Archiven, nur im Logbuch -> OK
• Timeout kommt / geht wird gar nicht in den DSfG-MW-Archiven eingetragen (liegt daran, dass Alarme erst in die DSfG-MW-Archive eingetragen werden, wenn eine Analyse beendet wird. Da aber beim Timeout keine Analyse mehr beendet wird, wird dieser Alarm auch nie in die DSfG-MW-Archive eingetragen!) -> OK
• Alarm kommt / geht ereignisorientiert?! D.h. wenn Ereignis auftritt sofort Eintrag ins DSfG-MW-Archive (genauso wie DSfG-Logbuch) und nicht auf beendete Analyse warten? -> OK
• MW-Eintrag wird als ungestört gekennzeichnet obwohl in dieser Stunde ein Fehler anlag -> OK
• Sekunden dürfen bei Alarm kommt / geht nicht abgeschnitten werden (Prüfen) -> OK

[Melanie Hermann]

DONE:

• Kal. kommt / geht hat nun auch in den DSfG-MW-Archiven einen sekundengenauen Zeitstempel
• Bei Kal. geht wird in der DSfG-DEI-Bitleiste auch 0x0200 gesetzt

[Melanie Hermann]

Änderungen:

• err_tab.txt:
  Zuordnung der DSfG-Fehlerkategorien angepasst
• utils.h:
  Neues enum eStream definiert
• gcerrors.cpp, SetDSfGError():
  
  • Verwendung von eStream
  • Bei eALL, eREF und eKAL werden für alle Streams Einträge erzeugt
  • Bei Störungen und Rechnerfehlern wird DEI neu gesetzt
• dsfgmana.cpp, Do_Archiv():
  
  • FILLEVT_NEUMESS führt nicht mehr zu zusätzlichen MW-Einträgen
  • FILLEVT_ALARM führt nun zu zusätzlichen MW-Einträgen (Aufruf von fillArchiv())
• dsfgmrg.cpp, fillArchivGruppe():
  • Einträge machen, wenn "fillEvent & FILLEVT_HALTEWERT & FILLEVT_ALARM"
• buildDSfGDei() prüft DO Kal. läuft und setzt entsprechend 0x0200
• arvFill_Alarm_Ana() sorgt mit FILLEVT_ALARM_ANA dafür, dass Alarme, die die Analyse beeinflussen, in die DSfG-MW-Archive eingetragen werden
• Bei Fehler geht werden die Bits im DEI in dem MW-Eintrag wieder gelöscht, sofern kein weiterer Fehler ansteht
• gcerrors.cpp, FehlerInGroupInStreamDa():
  Neue Funktion, die von buildDSfGDei() verwendet wird. Somit werden die Fehlerbits streamspezifisch gesetzt.
• Neue Matrixelemente angelegt um DEIs für Intervalle für jeden Stream zwischen zu speichern. (BitsLastG485[4], BitsLastStd[4], BitsLastTag[4], BitsLastMon[4])
• dsfgmrg.cpp, fillArchivGruppe():
  • Wenn Eintrag durch Intervall entsteht wird der entsprechende DEI verwendet und danach auf Null gesetzt
• DSFG.TAB:
  Vorher:

19  L  BitsMeas    S  BitsDay       - -   wnayd                 FRM_DSFG_HEX       // Bitleiste fuer Tagesarchiv
20  L  BitsMeas    S  BitsHour      - -   wnayd+dei+qei         FRM_DSFG_HEX       // Bitleiste fuer Stundenarchiv
25  L  BitsMeas    S  BitsMonth     - -   wnayf                 FRM_DSFG_HEX       // Bitleiste fuer Monatsarchiv
27  L  BitsMeas    S  BitsQuat      - -   wnayh+qei             FRM_DSFG_HEX       // Bitleiste fuer Viertelstundenarchiv

[Melanie Hermann]

Geklärt:

• Status von Neustart kommt / geht im DSfG-Logbuch grün. Ok? Soll nicht rot sein wie andere Fehler?
  Erklärung: Beim Schreiben des Eintrags in das Logbuch wird per gcwert::DSfGgetStatus() geprüft ob momentan noch ein Fehler anliegt. Wenn ja, was normalerweise der Fall ist, wird der Wert rot markiert (Fehler kommt). Wenn allerdings bei Gerätestart der Fehler POR kommt nachgetragen wird steht dieser Fehler ja nicht mehr an, somit wird der Eintrag grün markiert.
• GC-Log zeigt "Alarm GC9300" und DSfG-Logbuch zeigt "Neustart GC9300 (Bios)". Das liegt daran, dass die DSfG per dsfgEvtToErrnum() herausfindet um welche Fehlernummer es sich handelt. Nun ist es so, dass Fehler 8 (POR Bios) und 9 (POR) beide die DSfG-Fehlernummer 407 erhalten haben. Da nun die Schleife bei Fehler Nr.8 als erstes vorbei kommt und dort die DSfG-Fehlernummer findet, wird zurückgegeben, dass die DSfG-Fehlernr 407 zu GC-Fehlernr 8 gehört. Obwohl in manchen Fällen die GC-Fehlernr. 9 richtig wäre. Lösung: Die Fehlernummern gedreht. Jetzt erscheint die Meldung im DSfG-Logbuch immer ohne "Bios".