Format Funktionsbeschreibung

[Fragsau]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen,

ich beschäftige mich gerade mit dem Thema Funktionsbeschreibung.
Wir möchten gerne für jedes Projekt eine Funktionsbeschreibung erstellen, um damit von den vielen mündlichen und nebenbei Absprachen weg zu kommen.
Aber gut, der Mehrwert einer Funktionsbeschreibung ist ja klar.
Bisher haben wir das mal in Word, mal in Excel oder eben gar nicht gemacht.
Einfacher und super hilfreich wäre es ja, wenn es immer im gleichen Format und es eine Vorlage gibt.
Daher mal die Frage in die Runde:
Wie ist eure aufgebaut?
Welche Software nutzt ihr?
Was kommt alles rein, wie detailliert ist es?
Mir ist erstmal egal, welcher Maschinentyp beschrieben wird, da ich erstmal nur nach Ideen suche

Achso, primär sollte es natürlich als Unterstützung der Programmierer dienen, falls das relevant sein sollte.

Schon mal vielen Dank und bin auf die Rückmeldungen gespannt

 

[JSEngineering]

Es kommt ja bei Dir darauf an, ob Ihr "Module" programmiert, die immer wieder ähnlich sind. Ansonsten wird das ja nichts mit Vorlagen.

Ich gehe immer nach folgendem Muster vor:
Grobe Beschreibung des Projekts, damit auch ein Neuling im Thema sich was drunter vorstellen kann.
Grobe Beschreibung der Problemstellung des Projekts.
Aufdröseln des Problems in einzelne Einheiten, Beschreibung von Problemstellungen, Besonderheiten, Umsetzung, Anforderungen, die mit dem Kunden vereinbart sind.

Natürlich muß da der Programmierer was mit anfangen können, aber wie etwas umgesetzt wird, geht eigentlich den Kunden nichts an, weil das oft über seinen Horizont geht.
Daher Lastenheft (mit dem Kunden abgesprochene "Requirement specification") und dann intern ein Pflichtenheft ("Functional specification"). Im Pflichtenheft kann dann die programmatische Umsetzung detaillierter aufgeschlüsselt werden.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für Montageprozesse gibt es meistens dann vom (End)kunden eine Abtaktung, an der kann man sich dann entlang bewegen. Bei neuen Produkten welche noch nicht in Serie sind, kann sich das auch mal von Muster zu Muster ändern. Wir haben es dann immer so umgesetzt, das quasi es keine feste Prozesskette gibt, sondern alle möglichen Prozesse in sich gekapselt sind und vom Leitsystem vorgegeben werden kann, was in welcher Reheinfolge abgearbeitet wird. Hat den Vorteil dass du nicht auch noch darum kümmern musst, sondern dass die verschiedenen Optionen/Subsysteme das tun, was sie tun sollen.

 

[Fragsau]

Vielen Dank schon mal für das Feedback.

Mit Vorlage ist eher gemeint, dass ich ein Dokument mit schematischen Aufbau habe, welches mit führt bei der Erstellung der Beschreibung. Hat eben den Vorteil, dass es "gleich" aufgebaut ist und man dann weniger vergisst zu erwähnen.

Die Detail-Inhalte sind natürlich immer verschieden, da habe ich auch eine grobe Vorstellung.
Allerdings tue ich mir in der Form gerade etwas schwer.

In Word finde ich es nicht übersichtlich genug, gerade wenn es dann um Tabellen geht, ist es auch sperrig. In Excel kann man sich halt auch schnell verlieren...

Sind denn bei euch die Beschreibung so klein granular, dass die einzelnen Sensoren und deren Anforderungen beschrieben werden. Also in dem Beispiel:
Name des Senors -> Temperatursensor PT100
BMK -> -B1
Beschreibung -> Misst die Außentemperatur in °C
Erfassungsbereich -> -50 - 100°C
Erfassungsart (Bool, Widerstand, 0-10V..) -> PT100
Grenzwert MIN -> -1°C
Funktion Grenzwert MIN -> Warnung "Gießkanne frostsicher unterbringen"
Grenzwert MAX -> 30°C
Funktion Grenzwert MAX -> Warnung "Unbedingt ein Eis essen"

Ich hab das grad einfach mal zusammen gesponnen...

 

[JSEngineering]

Das würde ich trennen: Die Anforderungen in einem Dokument (Word) zusammenfassen, ggf. auf einzelne Sensoren/Aktoren verweisen.

Aber als Anhang/Begleitdokument würde ich eine Sensor- und ggf. Aktorliste führen. Je nach Informationsumfang können die ja schonmal zu Tapeten ausarten. Dort kann dann für jede Abteilung was drinstehen: Für den Einkauf die Bestellnummer und der Lieferant, für den programmierer der Wertebereich und die I/O-Adresse, für den Zeichner das BMK etc. etc.
Das würde ich nicht in einem Dokument verquicken.

Und wenn Ihr Euch da dann Vorlagen baut, kann man für die Abteilungen dann ggf. auch Sichten implementieren, so daß nicht jeder mit allen Informationen geflutet wird.

Ich denke, eine Vorlage müßt Ihr Euch erarbeiten, so daß es zu Eurer Strukur paßt. Arbeitet einer dran oder mehrere? Fang mit einer Vorlage an und entwickelt sie mit der Zeit.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habt ihr ein Qualitätsmanagementsystem/Zertifizierung nach DIN ISO 9000/9001 oder Beauftragte dafür? Vielleicht gibt es von daher schon (innerbetriebliche) Dokumente und Vorgaben?
Ab einer gewissen Projektgröße kommt man mit standardisierten Beschreibungen nicht mehr hin, da braucht man dann Sensor- und Aktor-Listen, die im Projektverlauf im Umfang wachsen und sich unterschiedlich entwickeln.

 

[Fragsau]

Das Dokument soll nicht abteilungsübergreifend sein, zumindest nicht primär.
Im besten Fall füllt es eber der aus, der sich das Projekt ausgedacht oder mit dem Kunden verhandelt hat.
Im Grund soll es nur eine Informationsbasis für die Programmierer sein.

Ich hab schon mit solchen Antworten gerechnet, dass es da kein "richtig" gibt, aber dachte, ich versuche es mal.

Nochmals vielen Dank.

Wenn jmd noch was hat, immer gerne

 

[JSEngineering]

Dann stellt sich ja primär schon die Frage: Hat der "der sich das Projekt ausgedacht oder mit dem Kunden verhandelt hat" auch die Ahnung, daß er z.B. (programmier-)technisch die Auswirkungen abschätzen kann?
In der Regel nicht.
Also beschränkt sich das Dokument da tatsächlich auf die Anforderungen.
Und das kann man ja eigentlich gut strukturiert aufbauen, wie ich das oben schon angedeutet hatte.

Und das muß dann ja intern von einem "der Ahnung hat" dann in eine funktionale Beschreibung umgesetzt werden (im Idealfalle). Je größer die Anlage, desto notwendiger dieser Schritt. Und da würde ich mich dann an den einzelnen Funktionen / Funktionseinheiten langhangeln. Also tatsächlich mehr oder weniger ohne Vorlage.

Für die Excel-Listen kann man hingegen gut Vorlagen erstellen... jeder sagt, welche Informationen er zu den Sensoren/Aktoren benötigt und das versucht man dann in einer mehr oder weniger großen Tapete strukturiert unterzubringen. Ggf. dann sogar mit Drop-Downs damit nicht jeder andere Angaben in einem Feld macht, sondern man dann aufgrund dieser (einheitlichen) Angaben ggf. auch mit Skripten arbeiten kann.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank schon mal für das Feedback.

Mit Vorlage ist eher gemeint, dass ich ein Dokument mit schematischen Aufbau habe, welches mit führt bei der Erstellung der Beschreibung. Hat eben den Vorteil, dass es "gleich" aufgebaut ist und man dann weniger vergisst zu erwähnen.

Die Detail-Inhalte sind natürlich immer verschieden, da habe ich auch eine grobe Vorstellung.
Allerdings tue ich mir in der Form gerade etwas schwer.

In Word finde ich es nicht übersichtlich genug, gerade wenn es dann um Tabellen geht, ist es auch sperrig. In Excel kann man sich halt auch schnell verlieren...

Sind denn bei euch die Beschreibung so klein granular, dass die einzelnen Sensoren und deren Anforderungen beschrieben werden. Also in dem Beispiel:
Name des Senors -> Temperatursensor PT100
BMK -> -B1
Beschreibung -> Misst die Außentemperatur in °C
Erfassungsbereich -> -50 - 100°C
Erfassungsart (Bool, Widerstand, 0-10V..) -> PT100
Grenzwert MIN -> -1°C
Funktion Grenzwert MIN -> Warnung "Gießkanne frostsicher unterbringen"
Grenzwert MAX -> 30°C
Funktion Grenzwert MAX -> Warnung "Unbedingt ein Eis essen"

Ich hab das grad einfach mal zusammen gesponnen...

Interessantes Thema und so gut wie überall chaotisch
Grundsätzlich ist das im Maschinenbau anders als im Anlagenbau.
Weiterhin unterschiedlich, ob jetzt Mechaniker und Automatisierer in einer Fa. sind oder getrennt...
Ich würds auf jeden Fall auch aufsplitten. Im Anlagenbau wirds meistens wie folgt gehandhabt:
Es gibt zuerst ne Komponentenliste (Excel), dort sind alle Feldgeräte mit Name, Bezeichnung, Hersteller, Typ und Hardwarefreigaben/verriegelungen aufgelistet. Das braucht der E-Planer.
Dann gibts ne Funktionsbeschreibung (Word), wo zu jedem Feldgerät aufgeführt ist, was es machen soll. Also bei Sensoren z.B. Grenzwertalarme, bei Aktoren Automatikansteuerung und Freigaben (Verriegelungen). Zusätzlich vielleicht noch ne Beschreibung übergreifender Teil- Automatikfunktionen. Schrittketten separat in Excel. In der Funktionsbeschreibung muss nicht stehn, obs jetzt Pt100 oder Pt1000 ist und auch nicht ob das Ventil jetzt 230VAC oder 24VDC versorgt wird. Das steht in der Komponentenliste.
Das ganze kann jetzt extrem ausführlich (5 Din A4 Seiten pro Feldgerät) oder eher einfach und kurz gehalten sein... Funktionsbeschreibung braucht eher der Programmierer.
Speziell bei komplizierten verfahrenstechnischen Anlagen kann sich der Programmierer die Funktionen nicht unbedingt selber ausdenken, dafür ist der Verfahrenstechniker/Anlagenbauer zuständig.

 

[ducati]

Für die Excel-Listen kann man hingegen gut Vorlagen erstellen... jeder sagt, welche Informationen er zu den Sensoren/Aktoren benötigt und das versucht man dann in einer mehr oder weniger großen Tapete strukturiert unterzubringen. Ggf. dann sogar mit Drop-Downs damit nicht jeder andere Angaben in einem Feld macht, sondern man dann aufgrund dieser (einheitlichen) Angaben ggf. auch mit Skripten arbeiten kann.

Wichtig hier ein funktionierendes "Änderungsmanagement" Also der Eplaner fängt mit der Liste schonmal an, alle par Tage kommt vom Technologen ne aktualisierte Liste, der Eplaner weiss nicht, was sich darin nun geändert hat... und vergleicht die ganze neue Liste mit seinen schon fertigen Arbeiten...
Kompliziertes Thema...

 

[Fragsau]

Ja ich sehe schon, dass wir es gar nicht so schlecht (oder sagen wir "anders") machen, aber es nicht so einfach wird das ganze zu optimieren..