Kierunki rozwoju systemów CAD: KBE (cz. III)
-- niedziela, 01 lipiec 2007 20:55
Kontynuując rozpoczęty w poprzednich odcinkach tego cyklu temat budowy inteligentnego środowiska projektowego w systemach CAD, chciałbym zwrócić uwagę Czytelnika na aspekt związany bezpośrednio z konstruktorem jako tym, który nie tylko korzysta z zasobów tego środowiska, ale także współuczestniczy w jego definicji i rozbudowie
Rezultat pracy konstruktora jest nierozerwalnie związany z jego wiedzą konstrukcyjną, a ta z kolei jest pochodną kilku lat nauki w szkole oraz wieloletniej praktyki konstrukcyjnej. Każdy konstruktor uczy się na swoich błędach i jeśli poważnie traktuje swój zawód, to pamięta lub zapisuje wnioski ze swoich niepowodzeń. Dzięki temu kolejna konstrukcja powstaje nieco inaczej, bo nie można oczekiwać, że powtarzanie tej samej (błędnej lub nieoptymalnej) procedury konstrukcyjnej przyniesie inne rezultaty. Każdy z nas (nie tylko konstruktor) posługuje się wiedzą zdobytą w wyniku doświadczenia. Na przykład, znając prognozę pogody na kolejny dzień, zabieramy ze sobą parasol – mimo, że nie widać jeszcze żadnych symptomów nadciągającego deszczu. Konstruktor wie, kiedy trzeba zastosować dwa żebra usztywniające zamiast jednego albo kiedy liczba otworów mocujących może być zbyt mała. Jeśli nie jest pewien, to zagląda do swoich notatek, zaleceń konstrukcyjnych, norm, poradników itd. Czas potrzebny na odnalezienie potrzebnej informacji jest oczywiście czasem straconym, bowiem w trakcie „poszukiwań” konstruktor nie posunął się ani o krok w realizacji swojego zadania projektowego. Dlatego dla każdego członka zespołu konstrukcyjnego powinno być oczywiste dążenie do gromadzenia wiedzy konstrukcyjnej w jednym, łatwo dostępnym dla innych miejscu. Nie trzeba chyba dodawać, że jeśli konstruktor pracuje w systemie CAD, to ta wiedza powinna być dostępna w tym właśnie systemie.
W tym kontekście można powiedzieć, że wiedza konstruktora wynika z odpowiedzi na dwa pytania:
Jak i dlaczego?
Słowo JAK kojarzy się zazwyczaj z wyborem metody i poleceń systemu CAD, które trzeba zastosować, aby uzyskać zakładany model geometryczny. Odpowiedź na pytanie DLACZEGO jest związana bardziej z technicznymi, a nie geometrycznymi aspektami konstruowania, bo wynika na przykład z uwzględnienia aspektów technologiczności lub sztywności projektowanego wyrobu. I tu dochodzimy do sedna systemów klasy KBE (Knowledge-Based Engineering) – przestrzenna definicja wyrobu (modelu części lub zespołu części) powinna obejmować model geometryczny oraz obiekty decydujące o jego inteligencji. Takimi obiektami mogą być: formuły obliczeniowe, zasady konstrukcyjne, warunki sprawdzające czy reakcje modelu na zdefiniowane zdarzenia konstrukcyjne (zmiana materiału, zwiększenie długości czę ści czy zmiana typu silnika). Każdy z tych obiektów może być zdefiniowany tylko przez tego, kto posiada odpowiednią wiedzę konstrukcyjną – potrafi przewidzieć różne sytuacje konstrukcyjne i odpowiedzieć na pytanie, dlaczego trzeba zareagować w określony sposób. Tym kimś jest oczywiście konstruktor, który definiuje nie tylko geometrię projektowanej części lub zespołu części, ale także zakres „inteligencji” projektowanego wyrobu. Wracając do cech środowiska projektowania trzeba zauważyć, że obiekty konstrukcyjne dostępne w tym środowisku (katalogi elementów typowych) powinny umożliwiać nie tylko automatyzację pewnych rutynowych zadań konstruktora, ale także pomagać lub wręcz wyręczać go w podejmowaniu poprawnych decyzji.
W tym aspekcie, omówione w poprzednim odcinku szablony konstrukcyjne zapewniają nie tylko powtórzenie znanej procedury konstrukcyjnej (metody konstrukcji modeli geometrycznych w systemie CAD), ale także dostosowanie zastosowanego komponentu standardowego do aktualnego środowiska geometrycznego oraz poprawną reakcję na zmiany wartości parametrów lub podstawowych elementów geometrycznych. Zanim jednak możliwa będzie definicja szablonu, trzeba zdefiniować, co może być szablonem i ustalić strukturę modelu wzorcowego takiego szablonu.
Na przykład: gdyby zadaniem konstruktora było zdefiniowanie modelu standardowej płyty mocującej, której kształt określają nie tylko typowe wymiary lub materiał, ale także rodzaj wykonania (LEWE lub PRAWE), to problem może rozwiązać prosta zasada konstrukcyjna WariantWykonania (rys. 1.). Istotą działania tej zasady jest sterowanie aktywnością operacji Symmetry.1 w zależności od wartości parametru Wykonanie.
RYS. 1
Taki model ma jednak pewne wady, bo jest ograniczony do takich części, które są lustrzanym odbiciem. Bardziej uniwersalne wydaje się w związku z tym rozwiązanie pokazane na rys. 2., w którym zasada Wariant Wykonania steruje aktywnością kilku cech konstrukcyjnych. Niestety struktura modelu staje się bardziej skomplikowana, a wszystkie elementy wyłączone (XXX\Activity = false) stanowią niepotrzebny „balast”.
RYS. 2
Oczywiście nie można oczekiwać, że możliwe jest zdefiniowanie modelu inteligentnej płyty mocującej bez elementów dodatkowych, ale trzeba poszukiwać możliwie prostego rozwiązania. Na przykład (rys. 3.) parametr KonturWybrania (typu Curve) może być konturem Sketch.2 lub Sketch.3 w zależności od wartości parametru Wykonanie. Wszystkie obiekty modelu są aktywne, choć trzeba przyznać, że tylko jeden z konturów Sketch.2 i Sketch.3 jest aktywnie zastosowany w definicji modelu bryłowego płyty mocującej.
Linki sponsorowane
![]() |
Almanach Produkcji w Polsce
Kompleksowy katalog w wersji on-online oraz drukowanej majacy na celu dostarczenie użytecznych informacji o dostawcach dla przemysłu jak i oferowanych przez nich produktach. |
|
Produkcja od A do Z w samym sercu polskiego przemysłu
Zapraszamy Państwa na VI edycję Targów Produkcji i Technologii PROTECH, które ponownie zagoszczą we Wrocławiu. |









zobacz wszystkie









