RevitCDE — solution overview

For buyers

01What this is

RevitCDE არის Common Data Environment Revit პროექტებისთვის.

ის მომხმარებლის მოქმედებებს კონკრეტულ მოდელის ობიექტებს უკავშირებს.

Key idea

შექმენით აუდიტირებადი ციფრული ციკლი.

For buyers

02For whom

RevitCDE გათვლილია რამდენიმე განსხვავებულ როლზე.

BIM coordinator / Project manager

ხედავს მოდელის, შეთანხმებების, დოკუმენტებისა და დავალებების მდგომარეობას.

Author (designer)

Revit-ში მუშაობს კონტექსტის მუდმივი შეცვლის გარეშე.

Approver

შემოსულ მოთხოვნებს snapshot-სა და დოკუმენტებთან ერთად ამოწმებს.

Viewer

წაკითხვის წვდომა პროექტის ფარგლების ფარგლებში.

Estimator

Estimate database, line items, non-model costs.

Planning engineer

Schedule, activities, non-model time processes.

Administrator

სერვერი, მომხმარებლები, პროექტები, მონაცემთა ბაზები და პოლიტიკები.

For buyers

03Problems we solve

წყვეტა Revit-სა და მართვის პროცესებს შორის

Why it hurts

შეთანხმებები და დავალებები მოდელისგან ცალკე ცხოვრობს.

როგორ ვაგვარებთ

პლაგინი იღებს მოდელის მონაცემებს და მოთხოვნებს ობიექტებთან აკავშირებს.

არ არსებობს სანდო მონაცემების ერთიანი წყარო

Why it hurts

ფაილები, ელფოსტა და ცხრილები ვერსიებში ერთმანეთს სცილდება.

როგორ ვაგვარებთ

CDE სტრუქტურა ინახავს პროექტებს, დოკუმენტებს, ვერსიებსა და ისტორიას.

Opaque approvals

Why it hurts

გადაწყვეტილებები იკარგება და მარშრუტები არაფორმალურია.

როგორ ვაგვარებთ

ApprovalRequest, multi-stage routes, append-only events, immutable snapshots.

მოდელის სტატუსი Revit-ში უხილავია

Why it hurts

პროექტანტი ვერ ხედავს, რა არის შეთანხმებული, განხილვაში ან უარყოფილი.

როგორ ვაგვარებთ

სტატუსები აისახება Shared Parameters-სა და Extensible Storage-ში.

3D, 4D და 5D ერთმანეთთან არ არის დაკავშირებული

Why it hurts

ხარჯთაღრიცხვა და გრაფიკი ცალ-ცალკე მუშაობს; არამოდელური სამუშაოები ხედვის არედან ქრება.

როგორ ვაგვარებთ

თითო პროექტზე estimate.db და schedule.db, ხოლო WorkPackage — 4D/5D-ის ცენტრალური კვანძი.

ოფლაინ / ლოკალური მუშაობა სერვერის გარეშე

Why it hurts

Detached მოდელებს სჭირდებათ ლოკალური საცავი ისე, რომ სერვერზე გადასვლის გზა არ დაიკარგოს.

როგორ ვაგვარებთ

ლოკალური რეჟიმი Extensible Storage-ში, სურვილისამებრ გარე ერთფაილიანი DB და შემდგომი მიგრაცია სერვერზე.

For buyers

04როგორ მუშაობს

სამი შრე ქმნის მონაცემთა ერთიან ციკლს.

მომხმარებელი Revit-ში მუშაობს. პლაგინი კითხულობს მოდელის ელემენტებს, ფურცლებს, ხედებს, სპეციფიკაციებსა და სტატუსებს.
მოდელი მიბმულია სერვერულ პროექტზე. მიბმა RVT მოდელის შიგნით Extensible Storage-ის საშუალებით ინახება.
პლაგინი სერვერთან ასინქრონებს პროექტის ელემენტებს, მოდელის ელემენტებს, ცვლილებებს, სტატუსებს, მოთხოვნებს, დავალებებს, ჩატებსა და დოკუმენტებს.
სერვერი გლობალურ მონაცემებს მთავარ ბაზაში ინახავს, საგნობრივ მონაცემებს კი თითო პროექტის ბაზებში: model_{guid}.db, disciplines.db, estimate.db, schedule.db.
ვებ-კაბინეტი აჩვენებს პროექტებს, დოკუმენტებს, შეთანხმებებს, დავალებებს, ჩატებსა და ადმინისტრირებას; realtime განახლებები SignalR-ით გადადის.
შემთანხმებლის გადაწყვეტილებები, სტატუსის ცვლილებები, დაკავშირებული დოკუმენტები და დავალებები Revit-ში ბრუნდება და პლაგინსა და მოდელის პარამეტრებში ჩანს.

Architectural principle

კოლაბორაციულ რეჟიმში სერვერი არის სანდო მონაცემების წყარო; მოდელი მაინც ინახავს მინიმალურ მიბმასა და ლოკალურ მონაცემებს, რათა მუშაობა გაგრძელდეს Revit-ის გადატვირთვისა და ოფლაინ პერიოდების დროს.

For buyers

05რას აკეთებს

ფუნქციური რუკა ერთი შეხედვით.

პროექტები

პროექტის გამართვა, მონაწილეები, როლები, სტანდარტები, დისციპლინები, ეტაპები და პაკეტები.

მოდელი

RVT binding, sync, identifiers, fingerprint, statuses, dirty tracking.

შეთანხმებები

Requests, routes, snapshots, decisions, withdrawal, journal, realtime.

Documents

CDE documents, versions, upload/download, SHA-256, WIP→Shared→Published→Archived.

დავალებები

Kanban, Gantt, importance, statuses, assignees, task relations.

კომუნიკაციები

Project chats, messages, reactions, correspondence, e-mail integration.

ადმინისტრირება

მომხმარებლები, როლები, სერვერის პარამეტრები, მონაცემთა ბაზები, health და ავტორიზაციის პოლიტიკები.

4D/5D

Estimate, schedule, WorkPackage, quantity snapshots, EVM/CPM.

Local work

Extensible Storage, სურვილისამებრ გარე ლოკალური DB და სერვერზე მიგრაცია.

ლოკალიზაცია

Centralised UI localisation, 22 languages by roadmap.

For buyers

06Usage scenarios

ფურცლის ან ხედის შეთანხმებაზე გაგზავნა

Step 1
Step 2
Step 3
Step 4
Step 5
Step 6

დოკუმენტი WIP-დან გამოქვეყნებამდე

Step 1
Step 2
Step 3
Step 4
Step 5

მოდელის, ხარჯთაღრიცხვისა და გრაფიკის დაკავშირება

Step 1
Step 2
Step 3
Step 4
Step 5

For buyers

07Frequently asked questions

Question 1

Answer 1

Question 2

Answer 2

Question 3

Answer 3

Question 4

Answer 4

Question 5

Answer 5

Question 6

Answer 6

Question 7

Answer 7

Question 8

Answer 8

Question 9

Answer 9

Question 10

Answer 10

Technical detail

08Solution composition

Component	დანიშნულება	Technology
`RevitCDE.Addin`	Revit add-in-ის შესვლის წერტილი, მოდელის მიბმა და ბრძანებების რეგისტრაცია.	C# /.NET Framework, Autodesk Revit API
`RevitCDE.UI`	Desktop პანელები, ბრძანებები და მომხმარებლის ურთიერთქმედება Revit-ის შიგნით.	WPF / MVVM
`RevitCDE.Core`	აპლიკაციის სერვისები, სინქრონიზაცია, ლოკალური საცავი და სერვერთან კომუნიკაცია.	C# services, HTTP clients, SQLite
`RevitCDE.Domain`	საერთო domain მოდელები, იდენტიფიკატორები, სტატუსები და ბიზნეს-წესები.	netstandard2.0 library
`RevitCDE.Server`	ცენტრალური API, ავთენტიფიკაცია, საპროექტო მონაცემები და ინტეგრაციის სერვისები.	ASP.NET Core 8, EF Core, PostgreSQL
`RevitCDE.Cabinet`	ვებ-კაბინეტი პროექტებისთვის, დოკუმენტებისთვის, შეთანხმებებისთვის, დავალებებისთვის, ჩატებისა და ადმინისტრირებისთვის.	TypeScript / React web UI
`RevitCDE.Localization`	თარგმანის ცენტრალური ლექსიკონები და ენის გადართვა მთელი ხილული UI-სთვის.	JSON dictionaries, shared i18n keys

Technical detail

09ლოკალური და სერვერული რეჟიმები

RevitCDE supports two runtime modes.

Local mode

მონაცემები მოდელის Extensible Storage-ში ინახება.

External local storage

ცალკე მონაცემთა ბაზის ფაილი თითო RVT მოდელზე.

Server mode

აქტიური მონაცემები სერვერზე ინახება.

Local & server modes

ლოკალურიდან სერვერზე მიგრაციის წესები.

Technical detail

10Storage architecture

Store	What it stores	რატომ მუშაობს ასე
Main server DB	მომხმარებლები, ორგანიზაციები, პროექტები, როლები, გლობალური პარამეტრები და ლიცენზიის მონაცემები.	პროექტთაშორის მონაცემებს ერთ ავტორიტეტულ სერვერულ ბაზაში ინახავს.
model_{guid}.db	მოდელის ელემენტები, ფურცლები, ხედები, სპეციფიკაციები, რაოდენობები და მოდელის დონის მიბმები.	დიდი მოცულობის მოდელის მონაცემები წარმადობისა და ტექნიკური მომსახურებისთვის თითო RVT მოდელზე იზოლირდება.
disciplines.db	პროექტის დისციპლინები, ეტაპები, პაკეტები და სტანდარტის მიხედვით განსაზღვრული დოკუმენტაციის სტრუქტურა.	პროექტის სტანდარტები შეიძლება გლობალური სქემის შეცვლის გარეშე განვითარდეს.
estimate.db	ხარჯთაღრიცხვის დოკუმენტები, პოზიციები, არამოდელური ხარჯები, რაოდენობებთან კავშირები და WorkPackage მიბმები.	ღირებულების მონაცემებს საკუთარი სასიცოცხლო ციკლი აქვს და უნდა მოიცავდეს მოდელში არარსებულ პოზიციებსაც.
schedule.db	გრაფიკის სამუშაოები, დამოკიდებულებები, არამოდელური დროითი პროცესები და WorkPackage კავშირები.	დაგეგმვის მონაცემებს CPM/Gantt ლოგიკა სჭირდება და შეიძლება ერთდროულად მოდელისა და ხარჯთაღრიცხვის მონაცემებს ეყრდნობოდეს.
Extensible Storage	მოდელის მინიმალური მიბმა, ტექნიკური იდენტიფიკატორები და ლოკალური fallback მონაცემები RVT-ის შიგნით.	მოდელი სერვერული გარემოს გარეთაც თვითიდენტიფიცირებადი რჩება.
External local DB	სურვილისამებრ ერთფაილიანი ლოკალური მონაცემთა ბაზა ჩატების, შეთანხმებების, დოკუმენტების, დავალებებისა და სხვა ლოკალური მონაცემებისთვის.	Detached/ლოკალურ მოდელებს შეუძლია უფრო მდიდარი მონაცემები შეინახოს Extensible Storage-ის ზედმეტი გადიდების გარეშე.

Technical detail

11Security and access

უსაფრთხოება აგებულია წევრობაზე, როლებზე, JWT-სა და ნდობის რეჟიმებზე.

JWT authentication.
პაროლების უსაფრთხო hash-ები; საწყის გამართვაზე bootstrap ადმინისტრატორი.
შესვლა მომხმარებლის სახელით, ელფოსტით ან ტელეფონით, თუ კონფიგურირებულია.
მომხმარებლის შესვლა ძირითადი რეჟიმია.
სურვილისამებრ სამუშაო სადგურის რეჟიმი პაროლის გარეშე.
მაღალი ნდობის მოქმედებებს კვლავ რეალური შესვლა სჭირდება.
პროექტის ფარგლებში Read / Write / Manage / Admin.

Technical detail

12შეთანხმებები — როგორ მუშაობს შიგნით

ფორმალიზებული და განმეორებადი პროცესი.

Submit for approval

არჩეული მოდელის რევიზიის ან დოკუმენტების პაკეტისთვის ქმნის შეთანხმების მოთხოვნას.

Immutable snapshot

აფიქსირებს შესამოწმებელი მოდელისა და დოკუმენტების ზუსტ მდგომარეობას, რათა გადაწყვეტილება განმეორებადი და დასაბუთებული დარჩეს.

Approval routes

განსაზღვრავს თანმიმდევრულ ან პარალელურ შემოწმების ნაბიჯებს, პასუხისმგებელ მონაწილეებსა და სავალდებულო გადაწყვეტილებებს.

Recorded decisions

ინახავს დამტკიცებებს, უარყოფებს, დაბრუნებებსა და კომენტარებს ავტორთან და დროის ნიშნულთან ერთად.

Event history

ინახავს გაგზავნების, დანიშვნების, გადაწყვეტილებებისა და სტატუსის ცვლილებების append-only ქრონოლოგიას.

Status synchronisation

დადასტურებულ შეთანხმების სტატუსს აბრუნებს პროექტის ობიექტებსა და დაკავშირებულ Revit workflow-ში.

Real-time updates

შეთანხმების ცვლილებებს დაკავშირებულ კლიენტებს გვერდის ხელით განახლების გარეშე აწვდის.

Technical detail

13WorkPackage — 4D/5D-ის ცენტრალური კვანძი

ცენტრალური ობიექტი, რომელიც მოდელს, რაოდენობებს, ხარჯთაღრიცხვას, გრაფიკსა და პროგრესს აკავშირებს.

`ModelElement`	სამუშაო პაკეტს BIM ელემენტებთან და მათ სტაბილურ იდენტიფიკატორებთან აკავშირებს.
`QuantityItem`	ინახავს გაზომილ რაოდენობებს და წყაროს, საიდანაც თითოეული რაოდენობა იქნა მიღებული.
`EstimateItem`	რაოდენობებს ხარჯთაღრიცხვის პოზიციებთან, ერთეულ ფასებთან და დათვლილ ღირებულებასთან აკავშირებს.
`WorkPackage`	ცენტრალური ობიექტის როლს ასრულებს, რომელიც მოცულობას, მოდელს, ღირებულებას, გრაფიკს, პასუხისმგებლობასა და მტკიცებულებებს აერთიანებს.
`ScheduleActivity`	სამუშაო პაკეტს დაგეგმილ აქტივობებთან, თარიღებთან, დამოკიდებულებებსა და კრიტიკული გზის მონაცემებთან აკავშირებს.
`ProgressSnapshot`	Stores actual progress, earned-value indicators and reporting-period facts.

Why no cross-DB FK

პროექტის მონაცემთა ბაზები საგნობრივი სფეროების მიხედვით არის გაყოფილი.

Technical detail

14Standards, disciplines, stages, packages

პროექტის სტანდარტი განსაზღვრავს დოკუმენტაციის, ხარჯთაღრიცხვისა და გრაფიკის ფორმატებს.

`ProjectStandard`

განსაზღვრავს პროექტის მოქმედ წესებს, სახელდების კონვენციებსა და სავალდებულო საინფორმაციო სტრუქტურას.

`დისციპლინა`

მართავს პროექტის დისციპლინების კატალოგსა და დისციპლინის სპეციფიკურ პასუხისმგებლობებს.

`PackageType`

განსაზღვრავს განმეორებით გამოსაყენებელ პაკეტურ სტრუქტურებს პროექტირების, შესყიდვისა და მშენებლობის სამუშაოებისთვის.

`ProjectStage`

მართავს პროექტის ეტაპებს, ეტაპებს შორის გადასვლებსა და თითოეულ ეტაპზე მოსალოდნელ მონაცემებს.

`ProjectRole`

განსაზღვრავს პასუხისმგებლობას, უფლებებსა და პროექტის ფარგლებში შეთანხმების უფლებამოსილებას.

`StandardPreset`

იყენებს სტანდარტების, დისციპლინების, ეტაპების, როლებისა და პაკეტის ტიპების განმეორებით გამოსაყენებელ ნაკრებს.

Technical detail

15REST API — primary groups

REST API by subject area, JWT-authenticated.

`/api/auth/*` · ავთენტიფიკაცია, ანგარიშის სესიები, პაროლის აღდგენა და წვდომის ტოკენები.
`/api/approvals/*` · შეთანხმების მოთხოვნები, მარშრუტები, გადაწყვეტილებები, კომენტარები და სტატუსის ცვლილებები.
`/api/cde/*` · პროექტები, მოდელები, დოკუმენტები, საკითხები და საერთო საპროექტო მონაცემები.
`/api/chats/*` · საპროექტო საუბრები, მონაწილეები, შეტყობინებები და დანართები.
`/api/tasks/*` · დავალებები, შემსრულებლები, ვადები, პრიორიტეტები და შესრულების მდგომარეობები.
`/api/standards/*` · პროექტის სტანდარტები, დისციპლინები, ეტაპები, როლები და პაკეტების preset-ები.
`/api/45d/*` · სამუშაო პაკეტები, რაოდენობები, ხარჯთაღრიცხვები, გრაფიკის სამუშაოები და პროგრესი.
`/api/admin/*` · ადმინისტრირება, კონფიგურაცია, დიაგნოსტიკა და კონტროლირებადი ტექნიკური მომსახურების ოპერაციები.

Technical detail

16Glossary

CDE: Common Data Environment — კონტროლირებადი სივრცე საპროექტო ინფორმაციის, კომუნიკაციისა და გადაწყვეტილებებისთვის.
Extensible Storage: Revit-ის მექანიზმი მოდელის შიგნით აპლიკაციის სტრუქტურირებული მონაცემების შესანახად.
Shared Parameters: Revit-ის პარამეტრები, რომლებიც საერთო definition ფაილის მეშვეობით პროექტებსა და family-ებს შორის გამოიყენება.
ProjectElement: პროექტის მხარეს არსებული ჩანაწერი, რომელიც BIM ელემენტს Revit დოკუმენტის გარეთ წარმოადგენს.
ModelElement: კონკრეტულ მოდელსა და მოდელის რევიზიაში ელემენტის სტაბილური მითითება.
Snapshot: შემოწმებისა ან შეთანხმებისთვის გამოყენებული საპროექტო მონაცემების ზუსტი მდგომარეობის უცვლელი ჩანაწერი.
ApprovalRequest: ფორმალური მოთხოვნა, რომელიც განსაზღვრულ მოცულობას შეთანხმების მარშრუტზე აგზავნის.
WorkPackage: The central 4D/5D object joining scope, quantities, cost, schedule and responsibility.
EVM: Earned Value Management — პროგრესის გაზომვა დაგეგმილი ღირებულების, შესრულებული ღირებულებისა და ფაქტობრივი ხარჯის გამოყენებით.
CPM: Critical Path Method — გრაფიკის ანალიზი სამუშაოების დამოკიდებულებებსა და ხელმისაწვდომ რეზერვზე დაყრდნობით.

Technical detail

17რა იგეგმება

მიმდინარე რეალიზაციას უკვე აქვს მუშა ბირთვი; ქვემოთ მოცემულია ის, რასაც შემდეგ ვავითარებთ.

Expanded localisation

ტერმინოლოგიის სრული გადახედვა და საგნობრივი ფორმულირებები ყველა მხარდაჭერილი ლოკალისთვის.

Document workflows

Versioned document registers, transmittals, review packages and evidence chains.

Deeper 4D/5D

სამუშაო პაკეტების უფრო დეტალური დაგეგმვა, ღირებულების კონტროლი, პროგრესის პროგნოზირება და earned-value ანალიზი.

BCF interoperability

საკითხებისა და viewpoint-ების გაცვლა სხვა BIM აპლიკაციებთან BCF სტანდარტის მეშვეობით.

Linked-model coordination

დაკავშირებული მოდელების, მფლობელობის, რევიზიებისა და მოდელთაშორისი დამოკიდებულებების კოორდინაცია.

Observability

ოპერაციული dashboard-ები, აუდიტის მეტრიკები, დიაგნოსტიკა და სერვისების ჯანმრთელობის მონიტორინგი.