Filosofie en documentatie

Toen ik voor Control Data (eigenlijk een dochteronderneming) werkte, kreeg elk schema een eenvoudig identificatienummer dat in oplopende volgorde was gerangschikt. Hetzelfde gold voor mechanische tekeningen en printplaten. Hoewel ik op de documentatieafdeling werkte, moet ik toegeven dat ik me niet kan herinneren hoe ze allemaal samenkwamen om de minicomputer te maken waaraan we werkten.

In die tijd werd alles met de hand gemaakt - het schema werd geschetst en aan de tekenafdeling gegeven en zij zouden het op perkament (ook overtrekpapier, hoewel beide concepten voor jongere lezers misschien net zo vreemd zijn als carbonpapier) met behulp van standaardsymbolen vaak omzetten uniformiteit bereiken met behulp van stencils. Een gespecialiseerde tekenaar zou de print uittekenen met dot en tape en een werktuigbouwkundig ingenieur zou de verpakking aan een tekentafel maken. Communicatie binnen het kantoor verliep via memo's, rapporten, vergaderingen en natuurlijk individuele interactie. Ik heb een blog gemaakt met mijn herinneringen aan hoe de dingen waren "Hoe het was:PCB-lay-out van Rubylith tot Dot en Tape tot CAD".

Naarmate het computerondersteunde ontwerp verbeterde, werden de tekeningen elektronisch met een papieren spoor, maar het was slechts een gemakkelijkere manier om de status-quo in documentatie te implementeren. Wat de PCB betreft, was het schema slechts een manier om de netlijst te krijgen. De mechanische tekening had een of twee stappen nodig om de PCB-uitvoer om te zetten naar een .dxf-bestand om in Autocad te importeren. Het was gemakkelijk om de verschillende documentuitvoer te scheiden en te categoriseren.

De producten waar ik aan werk, worden in fasen gebouwd, dus er zijn subassemblages. Wij hebben hier altijd last van gehad. Laten we aannemen dat we verschillende builds hebben met verschillende componenten. In de documentatiehiërarchie is er een punt waar er een gedeeltelijke build is die een gemeenschappelijk antecedent is. Op welk niveau hoort het schema? Bevindt het zich op het vroegste niveau, waar geen componentwaarden zijn toegewezen of is er een uniek schema op elk van de bovenste niveaus met de geselecteerde componentwaarde. Tot op zekere hoogte kan de keuze worden bepaald waarvoor het schema wordt gebruikt:wordt het gebruikt om het systeem te debuggen, biedt het een overzicht voor productie of wordt het gebruikt voor service.

In de loop der jaren is het documentatiesysteem van mijn werkgever inconsistent en willekeurig geëvolueerd. Aangezien we verschillende mensen hebben gehad die er invloed op hebben gehad en aangezien ze hun ervaring van andere organisaties hebben meegebracht, neem ik aan dat elementen ervan jullie allemaal bekend zullen voorkomen. Een van de belangrijkste principes die ik heb geprobeerd te implementeren, is afkomstig uit de lucht- en ruimtevaartindustrie. Er is slechts één bepaald document en het kan niet op twee plaatsen voorkomen, aangezien het omslachtig en foutgevoelig is om meer dan één document te onderhouden.

Figuur 1. Een van de iets complexere producten die we maken. De complete productlijst voor A bevat tekeningen die de zijlabels (B), de behuizing (C), de tekeningen voor het frontpaneel (D), de plug-in connectoren en tekeningen voor de labeling op de connector (E &F), de subassemblage (G) en niet getoond, de documenten voor de firmware die op de micro op G moet worden geprogrammeerd. De verpakking is ook toegevoegd. De subassemblage bestaat uit een printplaat en alle daarop gemonteerde componenten. Waar in de hiërarchie plaatsen we het schema? (Bron:Auteur)

Elk product dat we maken heeft een identificatienummer (meestal opeenvolgend toegewezen) dat we een "catalogusnummer" noemen. Alle documenten op hun niveau (top) in de hiërarchie bestaan ​​uit een letterprefix, het catalogusnummer en een suffix van de revisie. Het schema (rev C) van catalogusnummer 330924 zou bijvoorbeeld W330924C zijn, de mechanische tekening (ref F) zou M330924F zijn en de stuklijst (rev G) zou P330924G zijn. Als er een subassemblage is, krijgt deze een eigen volgnummer (bijv. SB00123) en worden de documenten die nodig zijn voor dat niveau genummerd volgens hetzelfde idee van een prefix-SB00123-suffix. Documenten zijn alleen aanwezig waar nodig, en het schema zou bijvoorbeeld naar het niveau van het gemeenschappelijk antecedent zakken. Componentwaarden die tussen builds kunnen veranderen, zijn gemarkeerd met een symbool dat aangeeft dat de waarde is gedefinieerd op de stuklijst. Mechanische assemblages en firmware volgen hetzelfde idee. Evenzo krijgt de PCB een volgnummer en revisie - geen voorvoegsels.

Maar de CAD-wereld is veranderd en het raadsel is raadselachtiger geworden. Pakketten zoals Altium integreren veel aspecten van het ontwerp. Het schema, de printplaat, de montagetekening, de mechanica en mogelijk zelfs de firmware maken allemaal deel uit van dezelfde ontwerpomgeving. Zozeer zelfs dat onze tekenaar erop staat dat de PCB de fysieke manifestatie van het schema is en dat beide dus altijd in dezelfde revisie moeten zitten. Dus als een componentwaarde verandert, moet de PCB-revisie veranderen! Wat doe je? En bovendien, wat is het nummer dat is toegewezen aan de schema-, montage- en mechanische tekeningen die worden gewijzigd wanneer de PCB wordt gewijzigd (inclusief mogelijk triviale dingen zoals zeefdrukupdates)? Waar in de hiërarchie bevinden ze zich - zijn ze gekoppeld aan het catalogusnummer of het PCB-nummer? En waar sla je ze op zodat wanneer een ingenieur een tekening bijwerkt, de tekenaar werkt vanuit de gewijzigde tekening en niet diegene die automatisch wordt opgeslagen als onderdeel van het PCB-pakket? HELP!

Kent iemand een systeem dat modern, consistent en indien mogelijk ergens beschreven is, zodat ik kan proberen ons systeem bij te werken? Kent iemand een PhD-student filosofie die op zoek is naar scriptiemateriaal? Voeg hieronder uw mening en beschrijvingen van uw ervaring toe.