Frequently Asked Questions

If you have further questions, please reach out via our Contact page.

About SysGit

What is SysML v2?

SysML v2 is the open systems modeling language developed by the OMG consortium, which includes many DIB organizations. SysML v2 supports enhanced model precision and quality, while supporting interoperability with other engineering models and tools, as well as usability for a wide range of engineering personas. SysML v2 introduces textual notation, allowing engineers to treat hardware as code, and a standard API.

What do you mean by Git for Hardware?

Git for Hardware describes both the agile hardware development process that SysGit supports, and the platform’s Git as the storage mechanism.

Agile Hardware Development:

Engineers use SysGit to complete parallel path hardware iteration enabled by battle-tested Git functions, such as branching and merging. We also adopt three key pillars from source control: the Data Repository, the Pull Request and Design Review, and Actions and Automations.

Git Providers as the Storage Mechanism:

SysGit relies on underlying Git providers as the storage mechanism for data, including GitHub, GitLab, and Gitea. SysGit allows users of these platforms to leverage software engineering infrastructure, including workflows and security, for hardware engineering.

I thought Git was used for software and web development. How can it help to build vehicles and weapon systems?

Git is already widely deployed on the high-side throughout the U.S. Defense Industrial Base. Git is built for the most battle-tested and distributed development process: the Linux kernel. Since it is both widely deployed and ready to serve complex engineering projects, Git can be adopted by organizations today. Other tools require inventing new ontologies, new languages, and inventing APIs. Still others are broken, expensive, and lead to data lock-in. Git inherits all of the underlying infrastructure that organizations have already configured, while affording the collaboration and automation that has revolutionized software development to hardware engineers.

Does SysGit support requirements management? What about MBSE?

Yes and yes. SysGit is built to accelerate the realization of the future envisioned by the last 30 years of development of Model Based Systems Engineering. We believe requirements and system-level models and are necessary for hardware engineers to collaborate between companies. However, existing tools are broken, expensive, and create vendor lock-in. Rather than new tools, SysGit provides engineers with code and platforms.

What is MOSA?

Modular Open Systems Approaches was mandated by the U.S. Defense Industrial Base throughout the defense ecosystem, as codified in Title 10 U.S.C. 4401(b).

This requires DoD and DIB organizations to “ensure that major system interfaces incorporate commercial standards and other widely supported consensus-based standards that are validated, published, and maintained by recognized standards organizations to the maximum extent practicable.”

SysML v2 fits this definition, as it is both a consensus-based standard, was developed by a recognized standards organization (OMG).

Along with conforming to standards, MOSA is designed to promote interoperability, and improve agility, allowing projects to deliver on schedule, budget, quality, and compliance.

Where in the engineering decision making process does SysGit come in?

SysGit addresses the area of interface management, which is designed to govern collaboration between teams and organizations, as well as ensure compliance. Primarily, SysGit serves organizations during the acquisitions process, as they are tracking builds and plans toward design elements. SysGit provides a digital deliverable that allows organizations to gain approval, in the same format as a pull request, and enter buy-off against competing requirements and source material. When approval is obtained, changes are propagated across the model, and across organizations.

What personas does SysGit serve?

SysGit explicitly supports three user personas: the Systems Engineer, the Individual Contributor, and an External Stakeholder.

We include a broad definition of Systems Engineer. This could be a project manager, systems engineer, responsible engineer, or otherwise an individual responsible for the cross-functional success of the system.

The Individual Contributor, whether a mechanical engineer building part of a structure, an analyst responsible for ensuring proper fluid flow, or a software developer detailing an autonomous system.

‍The External Stakeholder is considered as someone who is interested in the success of the system but is not directly contributing to its development; this could be an acquisitions official, a vendor, or a customer.

SysGit doesn’t require specialized systems engineering knowledge to capture a complex space system. This enables untrained, but technical individuals to interface directly with the space system, including warfighters, OEM’s, and program management offices.

Does SysGit integrate with CI/CD pipelines?

Since SysGit is built on git and open standards, we can immediately leverage existing CI/CD infrastructure to accelerate development, and support a diverse set of user personas. Systems Engineers perform usual work with SysGit, while DevOps & DevSecOps Engineers administer workflows in GitLab or GitHub. Information is safely captured in SysML v2 open standard.

Can you use SysGit alongside other tools?

Yes, since data is stored in an open standard (SysMLv2), organizations that use legacy tools can adopt SysGit alongside tools that are used in other parts of the process.

What about SysML?

SysGit is fully aware of the ongoing transition from SysML to SysML v2. We remain fully committed to and energized by SysML v2 and the significant improvements it brings, both in usability and interoperability. We chose this path over a more complicated architecture that would require inventing our own ontology and integrating with a requirements database via multiple tools, then mapping that to SysML v2 in the future. We stand as ready and willing partners in making this transition a success.

Security

Do you have Single Sign On (SSO) support?

Yes. SysGit does not store user information, and instead relies on Git Provider (GitLab or GitHub)’s SSO

Do you have Role Based Access Control (RBAC) support?

Yes. SysGit does not store user information. We instead inherit all RBAC settings as defined in the host Git provider (GitLab or GitHub).

Do you support audit logs?

Any creation, modification, or deletion of data is handled through the Git Provider’s API and will be available within the Git Provider.

Can SysGit access be limited at the network level?

Yes, SysGit can be isolated from the external internet. It only requires access to your Git Provider. If SysGit is on an airgapped network, then the Git provider must be on the same airgapped network.

How does the SysGit encrypt data?

At rest: SysGit does not ship with a database of any kind and does store any data outside of what it has cached from API calls.
In transit: SysGit uses HTTPS to encrypt all data in transit. All read and write activities are tied to users, who must login with the Git Provider and have access to do so in the first place

Does the application support customer managed encryption keys to encrypt customer data at-rest?

This is dependent on your Git provider, and your configuration of said provider.

What type of access do vendor employees have to customer data within the application?

None. SysGit does not store data, it is stored within your Git provider. However, if you have provisioned a third party user to access any repositories within your Git Provider, the same repositories will be available to them in SysGit.

Does the company provide results of any audits, pentests, or other security assessments?

Currently we have our SecureFrame Trust compliance status for Monitoring available here: https://prewitt-ridge.secureframetrust.com/