Hallo, bei einem unserer Kunden tritt immer wieder das Problem auf, dass es bei der Entwicklung von sehr komplexen Einsteckkarten und Backplanes zu Signalkollisionen oder falschen Signalrichtungen kommt. Zudem sind sowohl Backplanes als auch Karten einer gewissen Evolution unterworfen, so dass die Versionsstände noch als weitere Dimension hinzukommem. Kennt jemand von Euch auch schon einmal vor dem Problem, derartige Datenbestände zu erfassen und zu verwalten und möglichst auch noch Inkonsistenzen zu erkennen? Dabei sollten sehr unterschiedliche Eigenschaften von Bussystemen und Punkt-zu-Punkt-Verbindung berücksichtigt werden können, insbesondere auch Namenskonventionen und elektrische Besonderheiten. Beispiele: USB: - rein P2P - D+, D- heißen überall gleich - Vertauschung D+, D- zulässig PCI Express: - rein P2P - Bezeichnung TX, RX immer aus Sicht des jeweiligen Senders - CLK immer aus Sicht des Masters bzw. der Taktverteilung - TX+/- darf getauscht werden, ggf. abhängig von verwendeten Bausteinen - RX+/- darf getauscht werden, ggf. abhängig von verwendeten Bausteinen UART: - rein P2P - ... JTAG: - Verkettung mit gemeinsamen Signalen TMS, TCK - TDI nur Ausgang beim JTAG-Master, sonst Eingang - TDO nur Eingang beim JTAG-Master Ein Verwaltungsprogramm, wie ich es mir vorstelle, sollte die Möglichkeit besitzen, die Eigenschaften und Konventionen in Form von Regeln zu verwalten und Konflikte zu melden. Weiterhin sollte es in der Lage sein, Belegungspläne für Backplanes und Einsteckkarten zu erzeugen und dabei die richtigen Namenskonventionen für den konkreten Verwendungszweck auszuwählen bzw. zu generieren. Diese Pläne sollen sowohl als Listen für Bürosoftware (Word, Excel, usw.) als auch als Bibliothekssymbole oder sonstige importierbare Daten für Schaltplan und Layout zur Verfügung stehen. Ebenso sollte es möglich sein, "Experimente" zu machen, d.h. die Karten A, B, C in eine Backplane X hineinzustecken. Das Verwaltungsprogramm sollte dann alle möglichen Versionsstände durchprobieren und Konflikte melden. Dies soll sowohl für die entwicklungsinterne Planung neuer Karten als auch für Systemintegratoren beim Zusammenstellen komplexer Systeme nutzbar sein. Ich weiß, dass diese Anforderungen bei hinreichend feiner Aufdröselung sehr anspruchsvoll sind, aber im konkreten Fall würde es sich schon lohnen, da immer wieder sehr viel Lehrgeld gezahlt werden muss. Die typischen Programme wie z.B. ePLAN oder e3 sind ja eher für den Schaltschrankbau ausgelegt und bieten einheitliche Konventionen, aber keine "Intelligenz" bei der Erzeugung von Symbolen. Und EDA-Systeme wie z.B. EAGLE oder Altium Designer wollen auch immer einheitliche Namen sehen. Außerdem ermöglichen sie nur eine Sicht aus der aktuell in Bearbeitung befindlichen Baugruppe.
Ich hab mal für einen großen Telkom-Ausrüster in München :-) ein paar Konfiguratoren geschrieben, die in diese Richtung gingen. Nach dem Motto, wenn Modul A verbaut wird, muss der Steckplatz daneben unbedingt frei bleiben und dann gehen nur noch 2 x Modul B oder 1 x Modul C zusätzlich muss dann aber unbedingt auch Modul D verbaut werden usw. Da besagter Telekom-Ausrüster ein sehr breit gefächertes Angebot hat, wurde für jede Produkt-Familie ein eigener Konfigurator gebaut ... für die Pflege waren aber mehrere Vollzeit-Kräfte nötig. Ich vermute mal, dass das in Deinem Fall nicht ganz so komplex wird ... allerdings hast Du ja selbst schon erkannt, dass es nicht ohne ist, so ein System auf die Beine zu stellen. Bei Interesse können wir uns aber gerne mal näher über mögliche Details und Lösungsansätze unterhalten.
Günter M. schrieb: > Nach dem > Motto, wenn Modul A verbaut wird, muss der Steckplatz daneben unbedingt > frei bleiben Sowas lief mal unter der Bezeichnung "Expertensystem". Das scheint aber ziemlich aus der Mode gekommen zu sein. Die Idee war, das Wissen eines menschlichen Experten in Regeln zu erfassen, so dass er in vervielfachter Ausführung und unbegrenzt lange zur Verfügung steht. In der Praxis war es wohl nicht ganz so einfach, aber eigentlich ist das ganze ein alter Hut, meiner Erinnerung nach war der grosse Hype darum um 1990. Georg
Ich weis es nicht im Detail weil ich noch nicht damit gearbeitet habe, aber Tools wie Zuken CR-8000 gehen ganz klar weit über normales Leiterplattendesign hinaus und legen viel Wert auf Systemintegration. Ist allerdings kein billiger Spass. viel Erfolg hauspapa
Georg schrieb: > aber eigentlich ist das ganze ein alter Hut, meiner Erinnerung nach war > der grosse Hype darum um 1990. > > Georg da kannst Du mal sehen, wie lange ich schon dabei bin :-)
Günter M. schrieb: > Bei Interesse können wir uns aber gerne mal näher über mögliche Details > und Lösungsansätze unterhalten. Ja, das wäre interessant. Handelt es sich bei dem großen Telekomausrüster aus München um eine bekannte Großbank mit Elektrowarenhandlung? ;-) S. K. schrieb: > Ich weis es nicht im Detail weil ich noch nicht damit gearbeitet habe, > aber Tools wie Zuken CR-8000 gehen ganz klar weit über normales > Leiterplattendesign hinaus und legen viel Wert auf Systemintegration. > Ist allerdings kein billiger Spass. Oh, das ist eine sehr interessante Information, weil das Stammhaus unseres Kunden in der Tat mit CR-8000 arbeitet und auch einige Baugruppen beisteuert. Das Tochterunternehmen arbeitet aber mit Altium Designer, unter anderen um auch unabhängig von der zentralen CAD- und Bauelementestelle arbeiten zu können. Ob es sich lohnt, dafür auf CR-8000 umzusteigen, aber ich könnte sicherlich kompetente Ansprechpartner zu diesem Thema im Stammhaus finden, WENN sie CR-8000 für diesen Zwecks einsetzen... Georg schrieb: > Sowas lief mal unter der Bezeichnung "Expertensystem". Das scheint aber > ziemlich aus der Mode gekommen zu sein. Es ist hauptsächlich der Begriff "Expertensystem" aus der Mode gekommen, weil er doch arg mit "Künstlicher Intelligenz" verknüft war. Einige KI-Ansätze sind zwar gescheitert, aber vieles findet man auch heute unter neuem Namen wieder. Heutzutage haben sehr viele Anwendungsprogramme eine kontextsensitive Hilfe; diese hätte man vor dreißig Jahren schon als Expertensystem gefeiert und beworben. > Die Idee war, das Wissen eines menschlichen Experten in Regeln zu > erfassen, so dass er in vervielfachter Ausführung und unbegrenzt lange > zur Verfügung steht. In der Praxis war es wohl nicht ganz so einfach, > aber eigentlich ist das ganze ein alter Hut, meiner Erinnerung nach war > der grosse Hype darum um 1990. Damals dachte man, dass man mit vertretbarem Aufwand diese Expertensysteme dazu bringen konnte, die Regeln aus normaler menschlicher Sprache zu extrahieren. Das war damals in die Hose gegangen, weil menschliche Sprachen nicht formal genug spezifiziert sind und verwendet werden. Sehr viele Sprecher verwechseln "und" und "oder". Beispiel: "Die Lampe soll bei roten und blauen Dreiecken aufleuchten." Je nach Person und Kontext kann gemeint sein: 1. Die Lampe soll bei Vorhandensein mindestens eines roten oder eines blauen Dreiecks aufleuchten. 2. Die Lampe soll erst dann aufleuchten, wenn sowohl mindestens ein rotes und mindestens ein blaues Dreieck erkannt wurde. 3. Die Lampe soll erst dann aufleuchten, wenn sowohl mindestens ein rotes und mindestens ein blaues Dreieck zeitgleich vorhanden sind. 4. ... 5. ... Im konkreten Fall können wir aber davon ausgehen, dass diejenigen, die die Regeln pflegen sollten, diese in üblichen Abfrage- oder Programmiersprachen formulieren können. Konfiguratoren für alle möglichen Zwecke bzw. Produkte werden übrigens immer wichtiger, insbesondere bei Online-Shops, bei denen eben kein menschlicher Experte jeden Vorgang überwachen bzw. steuern kann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.